Information processing apparatus and information processing method

Abstract

This information processing apparatus comprises: an identification unit that identifies information about a delay request related to reflection of an operation of a user on a moving image content of extended reality (XR); an acquisition unit that acquires permission information regarding a transmission delay of a QoS flow allocated to a session established for an application related to the moving image content; and a determination unit that makes a determination, on the basis of the information about the delay request and the permission information, regarding generation of data related to the moving image content to be transmitted to a terminal apparatus used by the user.

Description

Information processing device and information processing method

[0001] The present disclosure relates to an information processing device and an information processing method.

[0002] Recent mobile networks (e.g., cellular networks such as 5G) require high communication performance (e.g., connection stability, low latency, high reliability, high throughput, power saving, low processing load, etc.). Among these, realizing stable low-latency wireless transmission is a very important element in realizing new communication services that have emerged in recent years (e.g., device control in IoT, real-time communication in games and VR, etc.).

[0003] Japanese Patent Application Laid-Open No. 2021-100256

[0004] However, with conventional technology, it is difficult to provide high-quality communication services to users. For example, in recent years, wireless distribution of media using XR technology to provide a highly realistic experience has been considered. In order to distribute such media wirelessly, stable low-latency wireless transmission must be achieved. However, it is difficult to achieve stable low-latency wireless transmission in a dynamically changing wireless environment. In this case, for example, the reflection of user actions in XR video content is delayed, making it difficult to provide high-quality communication services to users.

[0005] Therefore, the present disclosure proposes an information processing device and an information processing method that can provide high-quality communication services.

[0006] It should be noted that the above problem or object is merely one of multiple problems or objects that can be solved or achieved by multiple embodiments disclosed in this specification.

[0007] In order to solve the above problem, an information processing device of one embodiment according to the present disclosure includes an identification unit that identifies delay request information regarding reflection of a user's actions in XR (Extended Reality) video content, an acquisition unit that acquires tolerance information regarding the transmission delay of a QoS flow assigned to a session established for an application related to the video content, and a decision unit that makes a decision regarding generation of data related to the video content to be transmitted to a terminal device used by the user based on the delay request information and the tolerance information.

[0008] 1 is a diagram for explaining an overview of the present embodiment. FIG. 1 is a diagram illustrating a configuration of a communication system according to the present embodiment. FIG. 2 is a diagram illustrating an example configuration of a server according to an embodiment of the present disclosure. FIG. 3 is a diagram illustrating a configuration of a management device according to the present embodiment. FIG. 4 is a diagram illustrating a configuration of a base station according to the present embodiment. FIG. 5 is a diagram illustrating a configuration of a terminal device according to the present embodiment. FIG. 6 is a diagram illustrating an example configuration of a 5GS architecture. FIG. 7 is a diagram illustrating an example configuration of an XR architecture in 5G. FIG. 8 is a diagram illustrating an example QoS architecture for 5GS. FIG. 9 is a diagram illustrating standardized SST values. FIG. 10 is a diagram illustrating an example connection process in 5GS. FIG. 11 is a diagram illustrating an example PDU session establishment process. FIG. 12 is a diagram illustrating an example PDU session establishment process. FIG. 13 is a diagram illustrating an example process for reflecting an AF request in session routing. FIG. 14 is a diagram illustrating an example process for reflecting an AF request targeted at an individual UE in a policy. FIG. 15 is a diagram illustrating an example timing chart for each process in Generalized XR Split Rendering. FIG. 16 is a flowchart illustrating a session establishment process according to the first embodiment. FIG. 17 is a flowchart illustrating a setting process according to the first embodiment. FIG. 18 is a diagram illustrating an example image division method. FIG. 19 is a diagram illustrating another example image division method. FIG. 20 is a flowchart illustrating a setting process according to the second embodiment. FIG. 21 is a diagram illustrating a range of data to be transmitted to a terminal device. FIG. 22 is a flowchart illustrating an example configuration process according to the third embodiment. FIG. 23 is a flowchart illustrating another example configuration process according to the third embodiment. 10 is a flowchart showing an example of a process for specifying an image area taking into consideration the amount of movement of a display area. FIG. 11 is a flowchart showing an example of a setting process according to a fourth embodiment. FIG. 12 is a flowchart showing an example of a process for controlling the frequency of transmission of sensor information. FIG. 13 is a diagram showing an example of a timing chart related to control for displaying XR media on a terminal device. FIG. 14 is a flowchart showing an example of a setting process according to a seventh embodiment. FIG. 15 is a flowchart showing a setting process according to an eighth embodiment. FIG. 16 is a flowchart showing a setting process according to a ninth embodiment.

[0009] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. In the following embodiments, the same components are designated by the same reference numerals, and redundant description will be omitted.

[0010] In addition, in this specification and drawings, multiple components having substantially the same functional configuration may be distinguished by adding different numbers to the same reference numeral. For example, multiple components having substantially the same functional configuration may be distinguished by adding different numbers to the same reference numerals to the terminal device 40 as needed. １ , 40 ２ , and 40 ３ However, when there is no need to particularly distinguish between multiple components having substantially the same functional configuration, only the same reference numerals are used. For example, the terminal device 40 １ , 40 ２ , and 40 ３ When there is no need to particularly distinguish between them, they will be simply referred to as terminal devices 40.

[0011] One or more embodiments (including examples and variations) described below can be implemented independently. However, at least a portion of the embodiments described below may be implemented in appropriate combination with at least a portion of another embodiment. These embodiments may include novel features that are different from one another. Therefore, these embodiments may contribute to solving different purposes or problems and may produce different effects.

[0012] <<1. Overview>> The first standard for the fifth-generation mobile communications system (so-called 5G) was formulated as Rel-15 in 2018. 5G is a wireless access technology that can support a variety of use cases, including eMBB (Enhanced Mobile Broadband), mMTC (Massive Machine Type Communications), and URLLC (Ultra-Reliable and Low Latency Communications).

[0013] 5G will enable new wireless communication services. For example, 5G will enable device control in IoT and real-time communication in games and VR. 4G has also seen the emergence of wearable devices compatible with VR (Virtual Reality), primarily for gaming use cases. However, with 4G, it is difficult to deliver video content that requires real-time wireless transmission due to latency and throughput issues.

[0014] For 5G, a technology extension called XR is being discussed to enable low-latency and stable distribution of media. Here, XR stands for Extended Reality or Cross Reality. XR includes AR (Augmented Reality), MR (Mixed Reality), and VR (Virtual Reality). In the following explanation, Extended Reality can be replaced with Cross Reality.

[0015] As an example of XR-related technology, the cited document (JP 2021-100256 A) discloses a technology for setting multiple recommended viewports and specifying area information such as priority between the viewports when determining an area to be used as a viewport for virtual reality video data including subsections for a 360-degree view of a virtual environment.

[0016] However, with conventional technology, it is difficult to provide high-quality communication services to users. For example, consider a communication service that wirelessly distributes media for experiencing a highly realistic sensation, such as XR. In order for users to experience a highly realistic sensation with such media (e.g., XR video content), stable low-latency wireless transmission must be realized. However, it is difficult to realize stable low-latency wireless transmission in a dynamically changing wireless environment. In this case, for example, the reflection of user actions in XR video content (e.g., VR video) becomes slow, making it difficult to provide high-quality communication services to users.

[0017] Therefore, in this embodiment, the above problem is solved as follows.

[0018] 1 is a diagram for explaining an overview of the present embodiment. The communication system of the present embodiment includes an XR server and an XR device.

[0019] The XR server is a server device that distributes data related to XR media (for example, XR video content) to XR devices, which are terminal devices such as AR devices, VR devices, and MR devices.

[0020] Note that XR video content is not limited to XR videos such as VR videos. XR video content may also be XR games such as VR games. In addition, XR video content may be video content generated by calculating or processing 3D data (e.g., 3D space data and / or 3D object data) based on user viewpoint data.

[0021] The XR server and XR device of this embodiment are connected via a wireless access network such as 5G. In the example of Fig. 1, the XR device is a glasses-type device, but it may also be a head-mounted device.

[0022] The XR server specifies information on a delay request related to reflecting a user's actions in XR video content. The information on the delay request is a required value of PRPL (Pose to Render to Photon Latency) or RPL (Render to Photon Latency). The XR server may specify information on the delay request according to an application related to the video content. For example, the XR server may specify, as information on the delay request, a required value selected from a plurality of required values ​​of PRPL or RPL according to an application related to the video content. PRPL and RPL will be described later.

[0023] Then, the XR server acquires tolerance information regarding the transmission delay of the Quality of Service (QoS) flow assigned to the session established for the application related to the XR video content. The tolerance information regarding the transmission delay (hereinafter simply referred to as tolerance information) may include a Packet Delay Budget (PDB) of the QoS flow assigned to the session established for the application. For example, the tolerance information may include at least one of a PDB of an uplink QoS flow assigned to the session established for the application (hereinafter referred to as a first PDB) and a PDB of a downlink QoS flow assigned to the session established for the application (hereinafter referred to as a second PDB).

[0024] Then, the XR server makes a decision regarding the generation of data related to video content (hereinafter referred to as XR media content) to be transmitted to the XR device based on the delay request information and the tolerance information. For example, the XR server makes a decision regarding the generation of XR media content based on the delay request information and at least one of the first PDB and the second PDB. At this time, the decision regarding the generation of data related to video content may be a decision regarding at least one of the resolution and codec of the XR media content to be transmitted to the XR device.

[0025] The XR server may determine the image area to be transmitted to the XR device based on the tolerance information. At this time, the XR server may acquire sensor information from a sensor provided in the XR device and determine the image area based on the sensor information and the tolerance information. Then, the XR server may make a decision regarding the generation of the XR media content (determined image area) to be transmitted to the XR device (e.g., a decision regarding at least one of the resolution and the codec) based on the delay request information, the tolerance information, and the image area information.

[0026] The XR server then generates XR media content to be sent to the XR device according to the determined information (e.g., at least one of the resolution and the codec). The XR server then sends the generated XR media content to the XR device.

[0027] This allows the XR server to selectively set an appropriate resolution and codec for each of multiple XR applications that have different requirements for PRPL or RPL. As a result, the XR server can generate XR media content that matches the QoS flow assigned to the session. As a result, the XR server can provide the user with a high-quality XR communication service (for example, an XR service that stably and quickly follows the user's movements).

[0028] The outline of this embodiment has been described above, and the communication system 1 of this embodiment will now be described in detail.

[0029] <<2. Configuration of Communication System>> First, the configuration of the communication system 1 will be described.

[0030] 2 is a diagram showing the configuration of a communication system 1 according to this embodiment. The communication system 1 includes a server 10, a management device 20, a base station 30, and a terminal device 40. The communication system 1 provides users with a wireless network (mobile network) that enables mobile communication by having the wireless communication devices that make up the communication system 1 operate in cooperation with each other.

[0031] The wireless network of this embodiment may be, for example, a cellular network configured from a radio access network RAN ​​and a core network CN. The mobile network may include a terminal device 40. In this embodiment, a wireless communication device is a device having a wireless communication function, and in the example of Fig. 2, this corresponds to the base station 30 and the terminal device 40.

[0032] The communication system 1 may include a plurality of servers 10, a plurality of management devices 20, a plurality of base stations 30, and a plurality of terminal devices 40. In the example of FIG. 2, the communication system 1 includes a plurality of servers 10.１ and server 10 ２ The management device 20 includes the management device 20 １ and management device 20 ２ The communication system 1 also includes a base station 30. １ , base station 30 ２ , and base station 30 ３ The terminal device 40 is provided with the terminal device 40 １ , terminal device 40 ２ , and terminal device 40 ３ In the following description, the devices included in the communication system 1 may be referred to as network devices.

[0033] The terminal device 40 may be configured to connect to a network using radio access technology (RAT) such as LTE (Long Term Evolution), NR (New Radio), 6G, Wi-Fi, Bluetooth (registered trademark), etc. In this case, the terminal device 40 may be configured to be able to use different radio access technologies (wireless communication methods). For example, the terminal device 40 may be configured to be able to use NR and Wi-Fi. Furthermore, the terminal device 40 may be configured to be able to use different cellular communication technologies (e.g., LTE, NR, or 6G). In the following description, the terminal device 40 may be referred to as UE (User Equipment) 40.

[0034] LTE and NR are types of cellular communication technologies that enable mobile communication for terminal devices by arranging multiple areas covered by base stations in the form of cells. 6G, also a type of cellular communication technology, has the potential to become a technology that enables mobile communication for terminal devices by arranging multiple areas covered by base stations in the form of cells.

[0035] In the following description, "LTE" includes LTE-A (LTE-Advanced), LTE-A Pro (LTE-Advanced Pro), and EUTRA (Evolved Universal Terrestrial Radio Access). NR includes NRAT (New Radio Access Technology) and FEUTRA (Further EUTRA). A single base station 30 may manage multiple cells. In the following description, a cell corresponding to LTE is referred to as an LTE cell, and a cell corresponding to NR is referred to as an NR cell.

[0036] NR is the next generation (5th generation) radio access technology after LTE (4th generation communications including LTE-Advanced and LTE-Advanced Pro). NR is a radio access technology that can support various use cases, including eMBB (Enhanced Mobile Broadband), mMTC (Massive Machine Type Communications), and URLLC (Ultra-Reliable and Low Latency Communications). NR was standardized in 3GPP (registered trademark) Rel-15 as a technical framework that corresponds to the usage scenarios, requirements, and deployment scenarios of these use cases. Furthermore, beyond 5G and 6G, it is required to simultaneously achieve multiple axes of high speed, large capacity, low latency, high reliability, and multiple simultaneous connections.

[0037] 6G is the next generation of cellular communications technology after NR (5th generation mobile communications) and 5GS (5G system). 6G includes radio access technology and network technologies between base stations, core networks, and data networks. 6G also includes technologies for extreme connectivity of eMBB, mMTC, and URLLC, which were the main use cases or requirements of NR. 6G also includes new technologies in new areas. For example, 6G may include technologies related to AI (cognitive network, AI native air interface), sensing (including radar sensing and network as a sensor), and terahertz communications.

[0038] The wireless network may support at least one of radio access technologies (RATs) such as LTE (Long Term Evolution), NR (New Radio), and 6G. LTE, NR, and 6G are types of cellular communication technologies that enable mobile communication for terminal devices by arranging multiple areas covered by base stations in the form of cells. The wireless access method used by the communication system 1 is not limited to LTE, NR, and 6G, and may be other wireless access methods such as W-CDMA (Wideband Code Division Multiple Access) and cdma2000 (Code Division Multiple Access 2000).

[0039] Furthermore, the base station 30 may be a terrestrial station or a non-terrestrial station. The non-terrestrial station may be a satellite station or an aircraft station. If the non-terrestrial station is a satellite station, the wireless network may be a bent-pipe (transparent) type mobile satellite communication system.

[0040] In this embodiment, terrestrial stations and terrestrial base stations refer to base stations and relay stations installed on the ground. Here, "terrestrial" refers to terrestrial in a broad sense, including not only land but also underground, on water, and underwater. In the following description, the term "terrestrial station" may be replaced with "gateway."

[0041] Note that an LTE base station may be referred to as an eNodeB (Evolved Node B) or eNB. An NR base station may be referred to as a gNodeB or gNB. A 6G base station may be referred to as a 6G NodeB (6GNB). In LTE, NR, and 6G, a terminal device (also referred to as a mobile station or terminal) may be referred to as a UE (User Equipment). Note that a terminal device is a type of communication device and is also referred to as a mobile station or terminal.

[0042] The terminal device 40 may be able to connect to a network using a wireless access technology (wireless communication method) other than LTE, NR, 6G, Wi-Fi, or Bluetooth. For example, the terminal device 40 may be able to connect to a network using low power wide area (LPWA) communication. The terminal device 40 may also be able to connect to a network using proprietary wireless communication.

[0043] Here, LPWA communication refers to wireless communication that enables low-power, wide-range communication. For example, LPWA wireless refers to IoT (Internet of Things) wireless communication using a specific low-power radio (e.g., the 920 MHz band) or the ISM (Industry-Science-Medical) band. The LPWA communication used by the terminal device 40 may conform to the LPWA standard. The LPWA standard may be, for example, at least one of ELTRES, ZETA, SIGFOX, LoRaWAN, LTE-M, and NB-IoT. Of course, the LPWA standard is not limited to these and may be another LPWA standard.

[0044] Each wireless communication device shown in Fig. 2 may be considered as a device in a logical sense, i.e., a part of each wireless communication device may be realized by a virtual machine (VM), a container such as Docker, or the like, and these may be physically implemented on the same hardware.

[0045] In this embodiment, the concept of a wireless communication device includes not only portable mobile devices (terminal devices) such as mobile terminals, but also devices installed in structures or mobile bodies. The structures or mobile bodies themselves may be considered wireless communication devices. Furthermore, the concept of a wireless communication device includes not only terminal devices 40 but also base stations 30. A wireless communication device is a type of processing device or information processing device. A wireless communication device can also be referred to as a transmitting device or a receiving device.

[0046] Below, we will explain in detail the configuration of each wireless communication device that makes up the communication system 1. Note that the configuration of each wireless communication device shown below is merely an example. The configuration of each wireless communication device may be different from the configuration shown below.

[0047] <2-1. Server Configuration> First, the configuration of the server 10 will be described.

[0048] The server 10 is an information processing device (computer) that provides various services to the terminal device 40. For example, the server 10 is an XR server that distributes XR media such as XR video content to the terminal device 40. The server 10 may be an application server or a web server. The server 10 may be a PC server, a mid-range server, or a mainframe server. The server 10 may also be an information processing device that performs data processing (edge ​​processing) near a user or a terminal. For example, the server 10 may be an information processing device (computer) attached to or built into a base station. The server 10 may also have a core network function. For example, the server 10 may function as the management device 20. Of course, the server 10 may also be an information processing device that performs cloud computing. The server 10 of this embodiment can function as an application function.

[0049] The server 10 is connected to the management device 20 via a network N. Although only one network N is shown in the example of FIG. 2, there may be multiple networks N. Here, the network N is, for example, a public network such as the Internet. Note that the network N is not limited to the Internet, and may be, for example, a local area network (LAN), a wide area network (WAN), a cellular network, a fixed telephone network, or a regional Internet Protocol (IP) network. The network N may include a wired network or a wireless network.

[0050] 3 is a diagram illustrating an example configuration of the server 10 according to an embodiment of the present disclosure. The server 10 includes a communication unit 11, a storage unit 12, and a control unit 13. The configuration illustrated in FIG. 3 is a functional configuration, and the hardware configuration may be different from this. Furthermore, the functions of the server 10 may be distributed and implemented in multiple physically separated configurations. For example, the server 10 may be configured by multiple information processing devices.

[0051] The communication unit 11 is a communication interface for communicating with other devices. For example, the communication unit 11 is a network interface. For example, the communication unit 11 is a LAN (Local Area Network) interface such as a NIC (Network Interface Card). The communication unit 11 may be a wired interface or a wireless interface. The communication unit 11 communicates with the management device 20, the base station 30, the terminal device 40, and other servers 10 under the control of the control unit 13.

[0052] The storage unit 12 is a storage device that can read and write data, such as a dynamic random access memory (DRAM), a static random access memory (SRAM), a flash memory, or a hard disk.

[0053] The control unit 13 is a controller that controls each component of the server 10. The control unit 13 may be implemented by a processor such as a central processing unit (CPU) or a microprocessing unit (MPU). Specifically, the control unit 13 may be implemented by a processor executing various programs stored in a storage device within the management device 20 using a random access memory (RAM) or the like as a work area. The control unit 13 may be implemented by an integrated circuit such as an application-specific integrated circuit (ASIC) or a field programmable gate array (FPGA). The control unit 13 may also be implemented by a graphics processing unit (GPU). A CPU, an MPU, an ASIC, an FPGA, and a GPU can all be considered controllers. The control unit 13 may be configured by multiple physically separated entities. For example, the control unit 13 may be configured by multiple semiconductor chips.

[0054] The control unit 13 includes an identification unit 131, an acquisition unit 132, a determination unit 133, a division unit 134, a setting unit 135, a generation unit 136, a detection unit 137, a request unit 138, and a notification unit 139. Each block (identification unit 131 to notification unit 139) constituting the control unit 13 is a functional block indicating a function of the control unit 13. These functional blocks may be software blocks or hardware blocks. For example, each of the above-described functional blocks may be a software module realized by software (including a microprogram), or may be a circuit block on a semiconductor chip (die). Of course, each functional block may be a processor or an integrated circuit. The control unit 13 may be configured with functional units different from the above-described functional blocks. The method of configuring the functional blocks is arbitrary.

[0055] <2-2. Configuration of Management Device> Next, the configuration of the management device 20 will be described.

[0056] The management device 20 is an information processing device (computer) that manages the wireless network. For example, the management device 20 is an information processing device that manages communication of the base station 30.

[0057] The management device 20 may be a device constituting a core network CN. For example, the management device 20 may be a device having a function as an MME (Mobility Management Entity). The management device 20 may also be a device having a function as an AMF (Access and Mobility Management Function) and / or an SMF (Session Management Function). The MME, AMF, and SMF are control plane network function nodes in the core network CN. The management device 20 may be a device having a function as a control plane network function (6G CPNF) in 6G. The 6G CPNF may be composed of one or more logical nodes.

[0058] Of course, the functions of the management device 20 are not limited to MME, AMF, SMF, and 6G CPNF. The management device 20 may be a device having functions as a Network Slice Selection Function (NSSF), an Authentication Server Function (AUSF), a Policy Control Function (PCF), and a Unified Data Management (UDM). Furthermore, the management device 20 may be a device having functions as a Home Subscriber Server (HSS).

[0059] The management device 20 may have a gateway function. For example, the management device 20 may have a function as an S-GW (Serving Gateway) or a P-GW (Packet Data Network Gateway). The management device 20 may also have a UPF (User Plane Function) function. In this case, the management device 20 may have multiple UPFs. The management device 20 may also be a device that has a function as a 6G User Plane Network Function (6G UPNF).

[0060] The core network CN is composed of multiple network functions, and each network function may be consolidated into one physical device or distributed across multiple physical devices. In other words, the management device 20 may be distributed across multiple devices. Furthermore, this distributed distribution may be controlled so that it is executed dynamically. The base station 30 and the management device 20 form a single network, providing wireless communication services to terminal devices 40. The management device 20 is connected to the Internet, and the terminal devices 40 can use various services provided via the Internet via the base station 30.

[0061] The management device 20 does not necessarily have to be a device that constitutes the core network CN. For example, assume that the core network CN is a core network of W-CDMA (Wideband Code Division Multiple Access) or cdma2000 (Code Division Multiple Access 2000). In this case, the management device 20 may be a device that functions as an RNC (Radio Network Controller).

[0062] FIG. 4 is a diagram showing the configuration of the management device 20 according to this embodiment. The management device 20 includes a communication unit 21, a storage unit 22, and a control unit 23. The configuration shown in FIG. 4 is a functional configuration, and the hardware configuration may be different from this. Furthermore, the functions of the management device 20 may be statically or dynamically distributed and implemented in multiple physically separated configurations. The management device 20 may also be configured by multiple server devices.

[0063] The communication unit 21 is a communication interface for communicating with a wireless communication device (e.g., base station 30). The communication unit 21 may be a network interface or a device connection interface. The communication unit 21 may be a LAN (Local Area Network) interface such as a NIC (Network Interface Card), or a Universal Serial Bus (USB) interface configured by a USB host controller or a USB port. The communication unit 21 may be a wired interface or a wireless interface. The communication unit 21 is controlled by the control unit 23.

[0064] The storage unit 22 is a readable and writable storage device such as a DRAM, an SRAM, a flash memory, or a hard disk. The storage unit 22 stores, for example, the connection state of the terminal device 40. The storage unit 22 stores the state of the RRC (Radio Resource Control) of the terminal device 40 and the state of the ECM (EPS Connection Management) or the 5G System CM (Connection Management). The storage unit 22 may function as a home memory that stores location information of the terminal device 40.

[0065] The control unit 23 is a controller that controls each unit of the management device 20. The control unit 23 may be realized by a processor such as a CPU or MPU. In particular, the control unit 23 may be realized by a processor executing various programs stored in a storage device inside the management device 20 using RAM or the like as a work area. The control unit 23 may be realized by an integrated circuit such as an ASIC or FPGA. The control unit 23 may also be realized by a GPU. A CPU, MPU, ASIC, FPGA, and GPU can all be considered controllers. The control unit 23 may be composed of multiple physically separated objects. For example, the control unit 23 may be composed of multiple semiconductor chips.

[0066] <2-3. Configuration of Base Station> Next, the configuration of the base station 30 will be described.

[0067] The base station 30 is a wireless communication device that performs wireless communication with other wireless communication devices (e.g., terminal devices 40 or other base stations 30). The base station 30 may perform wireless communication with the terminal devices 40 via a relay station, or may perform wireless communication directly with the terminal devices 40.

[0068] The base station 30 is a device equivalent to a radio base station (such as a base station, Node B, eNB, gNB, or 6GNB) or a radio access point. The base station 30 may be a radio relay station. The base station 30 may be an optical device called a remote radio head (RRH). The base station 30 may be a receiving station such as a field pickup unit (FPU). The base station 30 may be an integrated access and backhaul (IAB) donor node or an IAB relay node that provides radio access lines and radio backhaul lines using time division multiplexing, frequency division multiplexing, or space division multiplexing.

[0069] The wireless access technology used by the base station 30 may be cellular communication technology. The wireless access technology used by the base station 30 may be wireless LAN technology. The wireless access technology used by the base station 30 may be low-power wide-area (LPWA) communication technology. However, the wireless access technology used by the base station 30 is not limited to these and may be other wireless access technologies. The wireless communication used by the base station 30 may be wireless communication using millimeter waves or wireless communication using terahertz waves. The wireless communication used by the base station 30 may be wireless communication using radio waves or wireless communication using infrared or visible light (optical wireless). Furthermore, the base station 30 may be capable of NOMA (Non-Orthogonal Multiple Access) communication with the terminal device 40. Here, NOMA communication refers to communication (transmission, reception, or both) using non-orthogonal resources. Note that the base station 30 may be capable of NOMA communication with other base stations 30.

[0070] The base station 30 may be able to communicate with the core network via a base station-core network interface (e.g., NG Interface, S1 Interface, etc.). This interface may be either wired or wireless. The base station may also be able to communicate with other base stations via an inter-base station interface (e.g., Xn Interface, X2 Interface, F1 Interface, etc.). This interface may be either wired or wireless.

[0071] The concept of a base station (also called a "base station device") includes not only a donor base station but also a relay base station (also called a "relay station"). A relay base station may be any one of an RF Repeater, a Smart Repeater, and an Intelligent Surface. The concept of a base station includes not only a structure with base station functions but also equipment installed in the structure.

[0072] Examples of structures include high-rise buildings, houses, steel towers, station facilities, airport facilities, port facilities, office buildings, school buildings, hospitals, factories, commercial facilities, stadiums, and other buildings. The concept of a structure includes not only buildings, but also non-building structures such as tunnels, bridges, dams, fences, and steel pillars, as well as equipment such as cranes, gates, and wind turbines. The concept of a structure includes not only land (ground in the narrow sense) or underground structures, but also water-based structures such as piers or megafloats, and underwater structures such as ocean observation facilities. A base station can also be referred to as an information processing device.

[0073] The base station 30 may be a donor station or a relay station (relay station). The base station 30 may also be a fixed station or a mobile station. A mobile station is a wireless communication device (e.g., a base station) configured to be mobile. In this case, the base station 30 may be a device installed in a mobile body, or may be the mobile body itself. For example, a relay station with mobility can be considered a base station 30 as a mobile station. Furthermore, devices that are inherently mobile and have base station functionality (at least part of the base station functionality), such as vehicles, UAVs (Unmanned Aerial Vehicles) represented by drones, and smartphones, also fall under the category of a base station 30 as a mobile station.

[0074] Here, the moving body may be a mobile terminal such as a smartphone or a mobile phone. The moving body may be a moving body that moves on land (ground in the narrow sense) (e.g., a vehicle such as an automobile, bicycle, bus, truck, motorcycle, train, or linear motor car), or a moving body that moves underground (e.g., in a tunnel) (e.g., a subway). The moving body may also be a moving body that moves on water (e.g., a ship such as a passenger ship, cargo ship, or hovercraft), or a moving body that moves underwater (e.g., a submersible vessel such as a submarine, submarine, or unmanned underwater vehicle). The moving body may also be a moving body that moves within the atmosphere (e.g., an aircraft such as an airplane, airship, or drone).

[0075] The base station 30 may be a terrestrial base station (ground station) installed on the ground. The base station 30 may be a base station located on a structure on the ground, or a base station installed on a mobile object moving on the ground. The base station 30 may be an antenna installed on a structure such as a building and a signal processing device connected to that antenna. The base station 30 may be the structure or the mobile object itself. "Ground" refers not only to land (ground in the narrow sense) but also to ground, on water, and underwater in a broad sense. The base station 30 is not limited to a terrestrial base station. If the communication system 1 is a satellite communication system, the base station 30 may be an aircraft station. From the perspective of a satellite station, an aircraft station located on Earth is a ground station.

[0076] The base station 30 is not limited to a ground station. The base station 30 may be a non-terrestrial base station device (non-terrestrial station) that can float in the air or space. The base station 30 may be an aircraft station or a satellite station.

[0077] A satellite station is a satellite station capable of floating outside the atmosphere. The satellite station may be a device mounted on a space vehicle such as an artificial satellite, or may be the space vehicle itself. A space vehicle is a vehicle that moves outside the atmosphere. The space vehicle may be at least one of an artificial satellite, a spacecraft, a space station, and a probe. Of course, the space vehicle may also be an artificial celestial body other than these. Note that a satellite that serves as a satellite station may be any of a low Earth orbiting (LEO) satellite, a medium Earth orbiting (MEO) satellite, a geostationary Earth orbiting (GEO) satellite, or a highly elliptical orbiting (HEO) satellite. The satellite station may be a device mounted on a low Earth orbiting (LEO), a medium Earth orbiting (MEO), a geostationary Earth orbiting (GEO), or a highly elliptical orbiting (HEO) satellite.

[0078] An aircraft station is a wireless communication device capable of floating in the atmosphere of an aircraft or the like. The aircraft station may be a device mounted on the aircraft or the like, or may be the aircraft itself. The concept of aircraft includes not only heavier-than-air vehicles such as airplanes and gliders, but also lighter-than-air vehicles such as balloons and airships. The concept of aircraft includes not only heavier-than-air vehicles or lighter-than-air vehicles, but also rotorcraft such as helicopters and autogyros. The aircraft station, or an aircraft equipped with an aircraft station, may be an unmanned aerial vehicle such as a drone.

[0079] The concept of unmanned aerial vehicles also includes unmanned aerial systems (UAS) and tethered unmanned aerial systems (UAS). The concept of unmanned aerial vehicles also includes lighter than air UAS (LTA) and heavier than air UAS (HTA). The concept of unmanned aerial vehicles also includes high altitude unmanned aerial system platforms (HAPs).

[0080] The coverage size of the base station 30 may be relatively large, such as a macrocell, or relatively small, such as a picocell. The coverage size of the base station 30 may also be extremely small, such as a femtocell. The base station 30 may have a beamforming function. The base station 30 may form a cell or service area for each beam. Additionally or alternatively, in addition to beamforming, which gives directionality to the beam, the base station 30 may have a function to pinpoint a desired wave to a specific point by further considering distance information from the antenna of the base station 30. This function may be called beam focusing or point forming.

[0081] Fig. 5 is a diagram showing the configuration of a base station 30 according to this embodiment. The base station 30 includes a wireless communication unit 31, a storage unit 32, and a control unit 33. However, the configuration shown in Fig. 5 is a functional configuration, and the hardware configuration may be different. Furthermore, the functions of the base station 30 may be distributed and implemented in multiple physically separated units.

[0082] The wireless communication unit 31 is a signal processing unit for wireless communication with other wireless communication devices (for example, terminal devices 40 or other base stations 30). The wireless communication unit 31 is controlled by the control unit 33. The wireless communication unit 31 supports one or more wireless access methods. The wireless communication unit 31 may support at least one of NR, LTE, and 6G. In addition to NR, LTE, and 6G, the wireless communication unit 31 may also support W-CDMA, cdma2000, and the like. The wireless communication unit 31 may also support automatic retransmission techniques such as HARQ (Hybrid Automatic Repeat reQuest).

[0083] The wireless communication unit 31 includes a transmission processing unit 311, a reception processing unit 312, and an antenna 313. The wireless communication unit 31 may include multiple transmission processing units 311, multiple reception processing units 312, and multiple antennas 313. When the wireless communication unit 31 supports multiple wireless access methods, each unit of the wireless communication unit 31 may be configured separately for each wireless access method. The transmission processing unit 311 and the reception processing unit 312 may be configured separately for LTE, NR, and 6G. The antenna 313 may be configured with multiple antenna elements, for example, multiple patch antennas. The wireless communication unit 31 may have a beamforming function. For example, the wireless communication unit 31 may have a polarization beamforming function using vertical polarization (V polarization) and horizontal polarization (H polarization) (or a polarization beamforming function using dual polarization in polarization directions 45 degrees and -45 degrees from the vertical direction).

[0084] The transmission processing unit 311 performs transmission processing of the downlink control information and downlink data. For example, the transmission processing unit 311 encodes the downlink control information and downlink data input from the control unit 33 using a coding method such as block coding, convolutional coding, or turbo coding. Here, the encoding may be performed using polar codes or low density parity check codes (LDPC codes). The transmission processing unit 311 then modulates the coded bits using a predetermined modulation method such as BPSK, QPSK, 16QAM, 64QAM, or 256QAM. In this case, the signal points on the constellation do not necessarily need to be equidistant. The constellation may be a non-uniform constellation (NUC). The transmission processing unit 311 then multiplexes the modulation symbols of each channel and the downlink reference signal and allocates them to predetermined resource elements. The transmission processing unit 311 then performs various signal processing on the multiplexed signal. For example, the transmission processing unit 311 performs processes such as conversion to the frequency domain by fast Fourier transform, addition of a guard interval (cyclic prefix), generation of a baseband digital signal, conversion to an analog signal, quadrature modulation, up-conversion, removal of unnecessary frequency components, power amplification, etc. The signal generated by the transmission processing unit 311 is transmitted from an antenna 313.

[0085] The reception processing unit 312 processes the uplink signal received via the antenna 313. For example, the reception processing unit 312 performs downconversion, removal of unnecessary frequency components, control of amplification level, quadrature demodulation, conversion to a digital signal, removal of guard intervals (cyclic prefixes), extraction of frequency domain signals by fast Fourier transform, and the like on the uplink signal. The reception processing unit 312 then separates uplink channels such as a PUSCH (Physical Uplink Shared Channel) and a PUCCH (Physical Uplink Control Channel) and an uplink reference signal from the signal that has undergone these processes. The reception processing unit 312 also demodulates the received signal using a modulation method such as Binary Phase Shift Keying (BPSK) or Quadrature Phase Shift Keying (QPSK) for the modulation symbols of the uplink channel. The modulation method used for demodulation may be 16QAM (Quadrature Amplitude Modulation), 64QAM, or 256QAM. In this case, the signal points on the constellation do not necessarily have to be equidistant. The constellation may be a non-uniform constellation (NUC). The reception processing unit 312 then performs decoding processing on the coded bits of the demodulated uplink channel. The decoded uplink data and uplink control information are output to the control unit 33.

[0086] The antenna 313 is an antenna device that converts electric current and radio waves into each other. The antenna 313 may be composed of a single antenna element, for example, a single patch antenna. The antenna 313 may be composed of multiple antenna elements, for example, multiple patch antennas. When the antenna 313 is composed of multiple antenna elements, the wireless communication unit 31 may have a beamforming function. The wireless communication unit 31 may be configured to generate a directional beam by controlling the directivity of a wireless signal using the multiple antenna elements. The antenna 313 may be a dual-polarized antenna. When the antenna 313 is a dual-polarized antenna, the wireless communication unit 31 may use vertical polarization (V polarization) and horizontal polarization (H polarization) (or dual polarization with polarization directions at 45 degrees and -45 degrees from the vertical direction) when transmitting a wireless signal. The wireless communication unit 31 may control the directivity of a wireless signal transmitted using vertical polarization and horizontal polarization (or dual polarization with polarization directions at 45 degrees and -45 degrees from the vertical direction). Furthermore, the wireless communication unit 31 may transmit and receive spatially multiplexed signals via multiple layers each consisting of multiple antenna elements.

[0087] The storage unit 32 is a readable and writable storage device such as a DRAM, an SRAM, a flash memory, or a hard disk.

[0088] The control unit 33 is a controller that controls each unit of the base station 30. The control unit 33 controls the wireless communication unit to perform wireless communication with other wireless communication devices (e.g., terminal devices 40 or other base stations 30). The control unit 33 may be implemented by a processor such as a CPU or MPU. Specifically, the control unit 33 may be implemented by a processor executing various programs stored in a storage device inside the base station 30 using RAM or the like as a work area. The control unit 33 may be implemented by an integrated circuit such as an ASIC or FPGA. The control unit 33 may also be implemented by a GPU. A CPU, MPU, ASIC, FPGA, and GPU can all be considered controllers. The control unit 33 may be composed of multiple physically separated objects. For example, the control unit 33 may be composed of multiple semiconductor chips.

[0089] In some embodiments, the base station 30 may be configured as a collection of multiple physical or logical devices. As an example, the base station 30 of this embodiment may be divided into multiple devices such as a baseband unit (BBU) and a radio unit (RU). The base station 30 may be interpreted as a collection of these multiple devices. Furthermore, the base station may be either a BBU or an RU, or may be both. The BBU and the RU may be connected by a predetermined interface such as an enhanced Common Public Radio Interface (eCPRI).

[0090] The RU may be referred to as an RRU (Remote Radio Unit) or an RD (Radio DoT). The RU may correspond to a gNB-DU (gNB Distributed Unit) described later. The BBU may correspond to a gNB-CU (gNB Central Unit) described later. The RU may be a device integrally formed with an antenna. The antenna of the base station 30, for example, an antenna integrally formed with the RU, may employ an Advanced Antenna System and support MIMO such as FD-MIMO or beamforming. The antenna of the base station 30 may have, for example, 64 transmitting antenna ports and 64 receiving antenna ports.

[0091] The antenna mounted on the RU may be an antenna panel consisting of one or more antenna elements, and the RU may be equipped with one or more antenna panels. The RU may be equipped with two types of antenna panels, a horizontally polarized antenna panel and a vertically polarized antenna panel. The RU may be equipped with two types of antenna panels, a right-handed circularly polarized antenna panel and a left-handed circularly polarized antenna panel, or an antenna panel with a polarization direction at 45 degrees from the vertical direction and an antenna panel with a polarization direction at -45 degrees from the vertical direction. Multiple antennas with these multiple polarization directions may be mounted on a single antenna panel. The RU may form and control an independent beam for each antenna panel.

[0092] A plurality of base stations 30 may be connected to each other. One or more base stations 30 may be included in a radio access network (RAN). In this case, the base station 30 may be simply referred to as a RAN, a RAN node, an AN (Access Network), an AN node, or the like. The RAN in LTE may be called an Enhanced Universal Terrestrial RAN (EUTRAN). The RAN in NR may be called an NGRAN. Furthermore, the RAN in 6G may be called a 6GRAN. The RAN in W-CDMA (UMTS) may be called a UTRAN.

[0093] An LTE base station 30 may be referred to as an eNodeB (Evolved Node B) or eNB. In this case, the EUTRAN includes one or more eNodeBs (eNBs). An NR base station 30 may be referred to as a gNodeB or gNB. In this case, the NGRAN includes one or more gNBs. A 6G base station may be referred to as a 6GNodeB, 6gNodeB, 6GNB, or 6gNB. In this case, the 6GRAN includes one or more 6GNBs. The EUTRAN may include a gNB (en-gNB) connected to a core network (EPC) in an LTE communication system (EPS). The NGRAN may include an ng-eNB connected to a core network 5GC in a 5G communication system (5GS).

[0094] When the base station 30 is an eNB, gNB, 6GNB, or the like, the base station 30 may be referred to as a 3GPP access. When the base station 30 is a wireless access point, the base station 30 may be referred to as a non-3GPP access. The base station 30 may be a radio extension device called an RRH (Remote Radio Head). When the base station 30 is a gNB, the base station 30 may be a combination of the gNB-CU and gNB-DU described above, or may be either a gNB-CU or a gNB-DU.

[0095] Here, the gNB-CU hosts multiple upper layers (e.g., RRC (Radio Resource Control), SDAP (Service Data Adaptation Protocol), PDCP (Packet Data Convergence Protocol)) of the access stratum for communication with the UE. On the other hand, the gNB-DU hosts multiple lower layers (e.g., RLC (Radio Link Control), MAC (Medium Access Control), PHY (Physical layer)) of the access stratum. That is, among the messages / information described below, RRC signaling (semi-static notification) is generated by the gNB-CU, while MAC The CE and DCI (dynamic notification) may be generated by the gNB-DU. Alternatively, some configurations of the RRC configuration (semi-static notification), such as IE:cellGroupConfig, may be generated by the gNB-DU, and the remaining configurations may be generated by the gNB-CU. These configurations may be transmitted and received over the F1 interface described below.

[0096] The base station 30 may be configured to be able to communicate with other base stations. When multiple base stations 30 are eNBs or a combination of eNBs and en-gNBs, these base stations 30 may be connected via an X2 interface. When multiple base stations 30 are gNBs or a combination of gn-eNBs and gNBs, these base stations 30 may be connected via an Xn interface. When multiple base stations 30 are a combination of gNB-CUs and gNB-DUs, these base stations 30 may be connected via the F1 interface described above. Messages / information (e.g., RRC signaling, MAC Control Element (CE), or Downlink Control Information (DCI)) described below may be transmitted between multiple base stations 30 via, for example, the X2 interface, the Xn interface, or the F1 interface.

[0097] A cell provided by the base station 30 may be referred to as a serving cell. The concept of a serving cell includes a PCell (Primary Cell) and an SCell (Secondary Cell). When dual connectivity is provided to the terminal device 40, the PCell and zero or more SCells provided by a Master Node (MN) may be referred to as a Master Cell Group. The dual connectivity may be at least one of EUTRA-EUTRA Dual Connectivity, EUTRA-NR Dual Connectivity (ENDC), EUTRA-NR Dual Connectivity with 5GC, NR-EUTRA Dual Connectivity (NEDC), NR-NR Dual Connectivity, NR-6G Dual Connectivity, and 6G-NR Dual Connectivity. Of course, dual connectivity is not limited to these.

[0098] The serving cell may include a PSCell (Primary Secondary Cell or Primary SCG Cell). When dual connectivity is provided to the terminal device 40, the PSCell provided by a Secondary Node (SN) and zero or more SCells may be referred to as a Secondary Cell Group (SCG). Unless special configuration (e.g., PUCCH on SCell) is performed, the Physical Uplink Control Channel (PUCCH) is transmitted by the PCell and PSCell but not by the SCell. Radio link failure is detected by the PCell and PSCell but not (does not need to be detected by) the SCell. As such, the PCell and PSCell play special roles among serving cells and are therefore also referred to as Special Cells (SpCells).

[0099] One cell may be associated with one downlink component carrier and one uplink component carrier. The system bandwidth corresponding to one cell may be divided into multiple BWPs (Bandwidth Parts). In this case, one or multiple BWPs may be configured in the terminal device 40, and one BWP may be used by the terminal device 40 as an active BWP. Radio resources available to the terminal device 40, such as a frequency band, numerology (subcarrier spacing), or slot format, may differ for each cell, component carrier, or BWP.

[0100] 2-4. Configuration of Terminal Device Next, the configuration of the terminal device 40 will be described.

[0101] The terminal device 40 is a wireless communication device (eg, UE (User Equipment)) that performs wireless communication with other wireless communication devices (eg, base stations 30 or other terminal devices 40).

[0102] The terminal device 40 is typically an XR device such as an AR (Augmented Reality) device, a VR (Virtual Reality) device, or an MR (Mixed Reality) device. In this case, the XR device may be a glasses-type device such as AR glasses or MR glasses, or a head-mounted device such as a VR head-mounted display. When the terminal device 40 is an XR device, the terminal device 40 may be a standalone device consisting only of a part worn by a user (e.g., a glasses part). Alternatively, the terminal device 40 may be a terminal-linked device consisting of a part worn by a user (e.g., a glasses part) and a terminal part (e.g., a smart device) linked to the part worn by a user.

[0103] As described above, the terminal device 40 is typically an XR device such as an AR device, a VR device, or an MR device. However, the terminal device 40 is not limited to an XR device. Any type of information processing device (computer) can be used as the terminal device 40. For example, the terminal device 40 may be a mobile terminal such as a mobile phone, a smart device (smartphone or tablet), a PDA (Personal Digital Assistant), or a notebook PC. The terminal device 40 may also be an imaging device (e.g., a camcorder) equipped with a communication function. The terminal device 40 may also be a motorcycle or a mobile broadcast vehicle equipped with a communication device such as an FPU (Field Pickup Unit). The terminal device 40 may also be an M2M (Machine to Machine) device or an IoT (Internet of Things) device. The terminal device 40 may also be a wearable device such as a smartwatch.

[0104] The terminal device 40 may be capable of NOMA communication with the base station 30. The terminal device 40 may be able to use an automatic repeat technique such as HARQ when communicating with the base station 30. The terminal device 40 may be capable of sidelink communication with another terminal device 40. The terminal device 40 may be able to use an automatic repeat technique such as HARQ when performing sidelink communication. The terminal device 40 may be capable of NOMA communication when performing sidelink communication with another terminal device 40. The terminal device 40 may be capable of LPWA communication with other wireless communication devices such as the base station 30. The wireless communication used by the terminal device 40 may be wireless communication using millimeter waves. The wireless communication used by the terminal device 40, including sidelink communication, may be wireless communication using radio waves, or wireless communication using infrared or visible light, i.e., optical wireless.

[0105] The terminal device 40 may be a mobile wireless communication device, i.e., a mobile device. The terminal device 40 may be a wireless communication device installed in a mobile device, or may be the mobile device itself. The terminal device 40 may be a vehicle that moves on a road, such as an automobile, bus, truck, or motorcycle, or a train that runs on a track, or may be a wireless communication device mounted on the vehicle. The mobile device may be a mobile terminal, or a mobile device that moves on land (in the narrow sense of the word), underground, on water, or underwater. The mobile device may also be a mobile device that moves within the atmosphere, such as an airplane, airship, balloon, or helicopter, or a mobile device that moves outside the atmosphere, such as an artificial satellite. The mobile device may also be a UAV (Unmanned Aerial Vehicle) such as a drone. The terminal device 40 may also be a wireless communication device mounted on the mobile device.

[0106] The terminal device 40 may be capable of simultaneously connecting to and communicating with a plurality of base stations 30 or a plurality of cells. When one base station 30 supports a communication area through a plurality of cells (e.g., pCell or sCell), the plurality of cells can be bundled together to enable communication between the base station 30 and the terminal device 40 by using carrier aggregation (CA) technology, dual connectivity (DC) technology, multi-connectivity (MC) technology, or the like. Alternatively, communication between the terminal device 40 and the plurality of base stations 30 can also be achieved via cells of different base stations 30 by coordinated multi-point transmission and reception (CoMP) technology.

[0107] The terminal device 40 may be a relay terminal that relays communications to a remote terminal.

[0108] Fig. 6 is a diagram showing the configuration of a terminal device 40 according to this embodiment. The terminal device 40 includes a wireless communication unit 41, a storage unit 42, a control unit 43, an input unit 44, an output unit 45, and a sensor unit 46. The configuration shown in Fig. 6 is a functional configuration, and the hardware configuration may be different from this. Furthermore, the functions of the terminal device 40 may be distributed and implemented in multiple physically separated units.

[0109] The wireless communication unit 41 is a signal processing unit for wireless communication with other wireless communication devices (for example, the base station 30 or other terminal devices 40). The wireless communication unit 41 is controlled by the control unit 43. The wireless communication unit 41 supports one or more wireless access methods. The wireless communication unit 41 may support at least one of NR, LTE, and 6G. In addition to NR, LTE, and 6G, the wireless communication unit 41 may also support W-CDMA, cdma2000, and the like. The wireless communication unit 41 may also support automatic retransmission techniques such as HARQ (Hybrid Automatic Repeat reQuest).

[0110] The wireless communication unit 41 includes a transmission processing unit 411, a reception processing unit 412, and an antenna 413. The wireless communication unit 41 may include multiple transmission processing units 411, multiple reception processing units 412, and multiple antennas 413. When the wireless communication unit 41 supports multiple wireless access methods, each unit of the wireless communication unit 41 may be configured separately for each wireless access method. The transmission processing unit 411 and the reception processing unit 412 may be configured separately for LTE, NR, and 6G. The antenna 413 may be configured with multiple antenna elements, for example, multiple patch antennas. The wireless communication unit 41 may have a beamforming function. For example, the wireless communication unit 41 may have a polarization beamforming function using vertical polarization (V polarization) and horizontal polarization (H polarization) (or a polarization beamforming function using dual polarization in polarization directions 45 degrees and -45 degrees from the vertical direction).

[0111] The storage unit 42 is a readable and writable storage device such as a DRAM, an SRAM, a flash memory, or a hard disk.

[0112] The control unit 43 is a controller that controls each unit of the terminal device 40. The control unit 43 controls the wireless communication unit to perform wireless communication with other wireless communication devices (e.g., a base station 30 or another terminal device 40). The control unit 43 may be implemented by a processor such as a CPU or MPU. In particular, the control unit 23 may be implemented by a processor executing various programs stored in a storage device internal to the terminal device 40 using RAM or the like as a work area. The control unit 43 may be implemented by an integrated circuit such as an ASIC or FPGA. The CPU, MPU, ASIC, and FPGA can all be considered controllers. The control unit 43 may be implemented by a GPU. The CPU, MPU, ASIC, FPGA, and GPU can all be considered controllers. The control unit 43 may be composed of multiple physically separated objects. For example, the control unit 43 may be composed of multiple semiconductor chips.

[0113] The control unit 43 includes a receiving unit 431, a transmitting unit 432, and a display control unit 433. Each block (receiving unit 431 to display control unit 433) constituting the control unit 43 is a functional block that indicates the function of the control unit 43. These functional blocks may be software blocks or hardware blocks. For example, each of the above-mentioned functional blocks may be a software module realized by software (including a microprogram), or may be a circuit block on a semiconductor chip (die). Of course, each functional block may be a processor or an integrated circuit. The control unit 43 may be configured with functional units different from the above-mentioned functional blocks. The method of configuring the functional blocks is arbitrary.

[0114] The input unit 44 is an input device that accepts various inputs from the outside. For example, the input unit 44 is an operation device that allows the user to perform various operations, such as a keyboard, a mouse, operation keys, or voice input. If a touch panel is employed in the terminal device 40, the touch panel is also included in the input unit 44. In this case, the user performs various operations by touching the screen with a finger or a stylus.

[0115] The output unit 45 is a device that outputs various types of information to the outside, such as sound, light, vibration, and image. The output unit 45 includes a display unit 451 that displays various types of information. The display unit 451 is, for example, a display device such as a liquid crystal display or an organic EL (Electro Luminescence) display. If a touch panel is employed in the terminal device 40, the display unit 451 may be a device integrated with the input unit 44. If the terminal device 40 is an XR device, the display unit 451 may be a transparent device that projects an image onto glasses, or a retinal projection device that projects an image directly onto the user's retina. The output unit 45 outputs various types of information to the user under the control of the control unit 43.

[0116] The sensor unit 46 is a sensor that acquires information about the position or attitude of the terminal device 40. For example, the sensor unit 46 is an acceleration sensor and / or a gyro sensor. For example, the sensor unit may be a 6DoF (Six degrees of freedom) sensor or a 3DoF (Three degrees of freedom) sensor. Note that the sensor unit 46 is not limited to an acceleration sensor and / or a gyro sensor. The sensor unit 46 may be an IMU (Inertial Measurement Unit), a geomagnetic sensor, an illuminance sensor, a ToF (Time of Flight) sensor, or an image sensor. The sensor unit 46 may also be a GNSS (Global Navigation Satellite System) sensor. The GNSS sensor may be a GPS (Global Positioning System) sensor, a GLONASS sensor, a Galileo sensor, or a QZSS (Quasi-Zenith Satellite System) sensor. Alternatively, the sensor unit 46 may be a camera (for example, an infrared camera or a light field camera), a LiDAR (Light Detection and Ranging), a millimeter-wave radar, or a combination of these sensors.

[0117] <<Configuration Example of 3.5G Communication System>> The configuration of the communication system 1 has been described above. Next, a specific configuration example of the communication system 1 of this embodiment will be described.

[0118] In the following description, a configuration of a fifth generation mobile communication system (5G) will be described as a specific configuration example of the communication system 1, but the communication system 1 is not limited to a fifth generation mobile communication system. The communication system 1 may be a fourth generation mobile communication system (4G) or a sixth generation mobile communication system (6G). Of course, the communication system 1 may be any other wireless communication system.

[0119] <3-1. 5GS Network Architecture> First, a network architecture that can be applied to the communication system 1 of the present embodiment will be described. Here, as an example of the architecture of the communication system 1, the architecture of the 5GS (5G System) will be described.

[0120] FIG. 7 is a diagram showing an example of the configuration of a 5GS architecture. The 5G core network CN is also called 5G Core (5GC) / NGC (Next Generation Core). The core network CN of this embodiment is configured by, for example, one or more management devices 20. Hereinafter, the 5G core network CN is also referred to as 5GC / NGC. The core network CN is connected to a UE (User Equipment) 40 via a RAN (Radio Access Network) / AN (Access Network) 510. The UE 40 is, for example, a terminal device 40 in the communication system 1.

[0121] An application server (AS) 10 that performs processing related to applications is connected to 5GS via the Internet. The application server 10 is, for example, a server 10 in the communication system 1. This enables the UE 40 to use applications via the 5G service.

[0122] If the entity providing the application has a contract such as a service level agreement (SLA) with a public land mobile network (PLMN) operator that provides 5G services, the application server 10 can be arranged in the core network CN as the DN 530. The application server 10 may be provided in the form of an edge server.

[0123] The 5GS control plane function group 540 is composed of a plurality of NFs (Network Functions). The plurality of NFs included in the control plane function group 540 include, for example, an Access and Mobility Management Function (AMF) 541, a Network Exposure Function (NEF) 542, a Network Repository Function (NRF) 543, a Network Slice Selection Function (NSSF) 544, a Policy Control Function (PCF) 545, a Session Management Function (SMF) 546, a Unified Data Management (UDM) 547, an Application Function (AF) 548, an Authentication Server Function (AUSF) 549, a UE radio Capability Management Function (UCMF) 550, a Time Sensitive Communication and Time Synchronization Function (TSCTSF) 551, and a Binding Support Function (BSF) 552.

[0124] The UDM 547 includes a UDR (Unified Data Repository) that stores and manages subscriber information, and an FE (Front End) that processes the subscriber information. The AMF 541 performs mobility management. The SMF 546 performs session management.

[0125] The UCMF 550 holds UE Radio Capability Information corresponding to all UE Radio Capability IDs in a PLMN (Public Land Mobile Network). The UCMF 550 is responsible for assigning each PLMN-assigned UE Radio Capability ID. The TSCTSF 551 and the BSF 552 will be described later.

[0126] The functions and services provided by the core network CN can be used via the AF 548 provided for the application, but in the case of a third-party application, it is necessary to conclude an SLA (Service Level Agreement) with the operator that manages the core network CN and be considered a trusted AF 548 by the core network CN.

[0127] Furthermore, from the viewpoint of security, a third-party AF 548 disposed outside the core network CN is generally configured to be connected to the core network CN via the NEF 542 .

[0128] Namf is a service-based interface provided by the AMF 541. Nsmf is a service-based interface provided by the SMF 546. Nnef is a service-based interface provided by the NEF 542. Npcf is a service-based interface provided by the PCF 545. Nudm is a service-based interface provided by the UDM 547. Naf is a service-based interface provided by the AF 548. Nnrf is a service-based interface provided by the NRF 543. Nnssf is a service-based interface provided by the NSSF 544. Nausf is a service-based interface provided by the AUSF 549. Nucmf is a service-based interface provided by the UCMF 550. Ntsctsf is a service-based interface provided by the TSCTSF 551. The Nbsf is a service-based interface provided by the BSF 552. Each NF exchanges information with other NFs via its respective service-based interface.

[0129] Each NF can request or subscribe to a service provided by another network function and receive a response or notification from the service. That is, each NF exchanges information with other NFs by means of request / response or subscribe / notification via each service-based interface.

[0130] The UPF (User Plane Function) 520 has a function of processing the user plane. The DN (Data Network) 530 has a function of enabling connection to MNO (Mobile Network Operator) proprietary services, the Internet, and third-party services. The UPF 520 functions as a transfer processing unit for user plane data processed by the application server 10. The UPF 520 also functions as a gateway connected to the RAN / AN 510.

[0131] Here, each NF of the core network CN can be configured using virtualization or a container. Each NF can be implemented on a cloud server. In 5GS, each NF can be dynamically and reconfigurably configured using SDN (Software Defined Network).

[0132] The RAN / AN 510 has a function of enabling connection with the RAN and connection with an AN other than the RAN. The RAN / AN 510 includes a base station called a gNB or ng-eNB. The RAN may also be called an NG (Next Generation)-RAN.

[0133] The functions of the RAN / AN 510 are divided into a CU (Central Unit) that processes L2 / L3 functions above the PDCP (Packet Data Convergence Protocol) sublayer, and a DU (Distributed Unit) that processes L2 / L1 functions below the RLC (Radio Link Control) sublayer. The functions of the RAN / AN 510 can be distributed and arranged via an F1 interface.

[0134] Furthermore, the functions of the DU are divided into an RU (Radio Unit) that processes the LOW PHY sublayer and the radio unit (Radio), and a DU that processes the RLC, MAC (Medium Access Control), and HIGH PHY sublayers. The functions of the RU can be distributed and arranged, for example, via a fronthaul that complies with eCPRI (evolved Common Public Radio Interface).

[0135] The functions of the CU and / or DU can be configured using virtualization or containers. The functions of the CU and / or DU can be implemented on a cloud server. In 5GS, the functions of the CU and / or DU can be dynamically and reconfigurably configured using SDN.

[0136] Between the UE 40 and the AMF 541, information is exchanged via a reference point N1. Between the RAN / AN 510 and the AMF 541, information is exchanged via a reference point N2. Between the SMF 546 and the UPF 520, information is exchanged via a reference point N4.

[0137] The SMF 546 performs QoS control for each service data flow. The QoS control of the SMF 546 can be applied to both IP and Ethernet type service data flows. By performing QoS control for each service data flow, the SMF 546 provides authorized QoS for each specific service.

[0138] The SMF 546 can utilize indicators such as QoS subscriber information in conjunction with service-based, subscription-based, or predefined PCF internal policy rules.

[0139] The SMF 546 uses the Policy and Charging Control (PCC) rules associated with the QoS flow, i.e., the QoS-controlled data flow, to determine the QoS to authorize for the QoS flow.

[0140] When a QoS flow is deleted, the SMF 546 can notify the PCF 545 that the QoS flow has been deleted. Furthermore, when the SMF 546 cannot guarantee the bit rate guaranteed by the QoS flow, i.e., the Guaranteed Flow Bit Rate (GFBR), it can notify the PCF 545 that the GFBR cannot be guaranteed.

[0141] The QoS reservation procedure for a QoS flow can be to establish a UE-initiated QoS flow, and the QoS can be downgraded or upgraded as part of the QoS flow modification procedure.

[0142] <3-2. Architecture of XR in 5G> Figure 8 is a diagram showing an example of the architecture of XR in 5G. More specifically, Figure 8 is a diagram showing the architecture of a use case called "Generalized XR Split Rendering" described in 3GPP TR26.928 "Extended Reality (XR) in 5G".

[0143] This architecture is composed of an XR server 60 and an XR device 70 (e.g., XR Capable UE). The XR server 60 corresponds to the server 10 described above. In the example of the 5GS network architecture shown in FIG. 7, the XR server 60 corresponds to the DN 530 or the application server 10. The XR device 70 corresponds to the terminal device 40 described above. In the example of the 5GS network architecture shown in FIG. 7, the XR device 70 corresponds to the UE 40.

[0144] <XR Server> The XR server 60 includes an XR media generation unit 61, an XR display area pre-rendering unit 62, a 2D / 3D media encoding unit 63, an XR rendering metadata processing unit 64, an XR media content distribution unit 65, and a 5GS distribution unit 66.

[0145] The XR media generation unit 61 generates XR media adapted to the display area according to tracking and sensor information received from the XR device 70.

[0146] The XR display area pre-rendering unit 62 performs adaptive rendering of the display area according to tracking and sensor information received from the XR device 70.

[0147] The 2D / 3D media encoding unit 63 encodes the 2D / 3D media that constitutes the XR media.

[0148] The XR rendering metadata processing unit 64 generates the metadata required to render the XR media.

[0149] The XR media content distribution unit 65 distributes XR media content including encoded 2D / 3D media and metadata for rendering to the XR device 70 via the 5GS distribution unit 66.

[0150] Furthermore, the XR media content distribution unit 65 can use a Real-time Transport Protocol (RTP) such as WebRTC when distributing XR media content. Generally, RTP uses User Datagram Protocol (UDP) as the transport layer protocol, and applies forward error correction (FEC) to omit the retransmission control used in Transmission Control Protocol (TCP).

[0151] The XR media content distribution unit 65 or the 5GS distribution unit 66 may provide QoS control depending on the encoding format of the 2D / 3D media or its position in the display area.

[0152] For example, for foveated rendering, the XR media content distribution unit 65 or the 5GS distribution unit 66 may transmit data in a high-resolution format with a high priority and data in a low-resolution format with a low priority. Alternatively, the XR media content distribution unit 65 or the 5GS distribution unit 66 may transmit data in a central region of the display area with a high priority and data in a region away from the center of the display area with a low priority. Foveated rendering is a technology that maintains high resolution in the center of the field of view and reduces resolution as it moves outward from the field of view, thereby reducing the required data size without causing visual degradation as much as possible.

[0153] <XR Device> The XR device 70 (e.g., XR Capable UE) includes a 3DOF (Degrees Of Freedom) / 6DOF tracking and XR sensor unit 71, an XR media content distribution unit 72, a 5GS distribution unit 73, a 2D / 3D media decoding unit 74, an XR rendering metadata processing unit 75, an XR display area rendering unit 76, and a display unit 77.

[0154] The 3DOF / 6DOF tracking and XR sensor unit 71 acquires pose information (posture information) of the user as tracking information for identifying the display area (viewport). This pose information is included in tracking and sensor information in the XR media content distribution unit 72 and provided to the XR server 60. For example, the tracking and sensor information may include inertial information acquired by the 3DOF / 6DOF tracking and XR sensor unit 71 in addition to or instead of the pose information. In the following description, the tracking and sensor information may be simply referred to as sensor information.

[0155] The 3DOF / 6DOF tracking and XR sensor unit 71 is composed of, for example, a Global Navigation Satellite System (GNSS), a geomagnetic sensor, an acceleration sensor, a gyro sensor, an illuminance sensor, an infrared camera, a light field camera, a Light Detection and Ranging (LiDAR), a camera (image sensor), a Time of Flight (ToF) sensor, a millimeter wave radar, etc. The 3DOF / 6DOF tracking and XR sensor unit 71 corresponds to the sensor unit 46 of the terminal device 40.

[0156] The XR media content distribution unit 72 receives XR media content including a display area from the XR server 60 via the 5GS distribution unit 73. Here, the XR media content is composed of 2D / 3D media and metadata for rendering the XR media.

[0157] The 2D / 3D media decoding unit 74 decodes the 2D / 3D media that constitutes the XR media content received via the 5GS distribution unit 73 and the XR media content distribution unit 72.

[0158] The XR rendering metadata processing unit 75 processes metadata for rendering XR media that constitutes the XR media content received via the 5GS distribution unit 73 and the XR media content distribution unit 72.

[0159] The metadata includes projection information, which can be used to generate a 3D mesh and is also used to map a spherical image onto a 2D texture signal.

[0160] A 3D mesh is a polygon mesh, a collection of vertices, edges, and faces that defines the shape of a polyhedral object in, for example, 3D computer graphics or solid modeling. Objects generated by a polygon mesh are represented by various types of elements, such as vertices, edges, faces, polygons, and surfaces.

[0161] 3D meshes are also generated using point clouds, which are used in various fields of 3D modeling, such as medical imaging, architecture, 3D printing, manufacturing, 3D games, and XR applications. A point cloud is a collection of data points defined in a given coordinate system. For example, in a 3D coordinate system, a point cloud can define the shape of a real or fictional physical system.

[0162] Furthermore, a scene description enables the generation of various 3D scenes for XR applications. A scene description is also called a scene graph. A scene description is a directed acyclic graph (DAG) that hierarchically organizes the geometric arrangement of a scene based on objects, and typically has a simple tree structure. Leaf nodes in the graph represent geometric building blocks for generating shapes, such as polygons. Each node in the graph holds a pointer to a child node, which is a group of other nodes, a geometric element, a transformation matrix, etc. Spatial transformations are represented as graph nodes and are represented by transformation matrices. Other scene graph nodes include 3D objects or parts thereof, light sources, particle systems, display cameras, etc.

[0163] The XR display area rendering unit 76 renders the 2D / 3D media decoded by the 2D / 3D media decoding unit 74, taking into consideration the metadata processed by the XR rendering metadata processing unit 75 and the user's latest pose information acquired from the 3DOF / 6DOF tracking and XR sensor unit 71.

[0164] The XR display area rendering unit 76 may include a function called time warp. Time warp is a function for reducing motion to photon latency (MPL), which can cause VR sickness. The XR device 70 using the time warp function determines the latest display area (second display area) to be corrected from the current display area (first display area) based on, for example, 3DOF / 6DOF tracking and the latest inertial information acquired from the XR sensor unit 71. The XR device 70 then performs coordinate transformation to convert XR media adapted to the first display area into XR media adapted to the second display area.

[0165] The display unit 77 displays the 2D / 3D media rendered by the XR display area rendering unit 76. The display unit 77 corresponds to the display unit 451 of the terminal device 40.

[0166] Note that each block constituting the XR device 70 and the XR server 60 shown in Fig. 8 represents a logical function. Therefore, these functions may be implemented in an aggregated manner, or may be implemented by dividing them into more detailed functions. Furthermore, these functions may be implemented by distributing them statically or dynamically across multiple devices.

[0167] For example, the 5GS distribution unit 73 of the XR device 70 may be realized by the functions of the UE 40. Furthermore, the 5GS distribution unit 66 of the XR server 60 may be realized by the functions of the RAN / AN 510 and the core network CN. In this way, services such as XR are required to handle a wide range of data, from relatively small volumes of data such as pause information and inertial information to large volumes of data such as XR media. Furthermore, services such as XR are expected to be able to apply different QoS controls depending on the type of data.

[0168] <3-3. 5GS QoS Control> Figure 9 shows an example of a 5GS QoS architecture (based on 3GPP TS38.300). Figure 9 is based on 3GPP TS38.300. At the NAS (Non-Access Stratum) level, a QoS flow is the finest granularity for distinguishing different QoS within a PDU (Protocol Data Unit) session. Within a PDU session, a QoS flow is identified by a QFI (QoS Flow ID).

[0169] In addition, in Extended Reality (XR) and media services, a group of packets may be transmitted using the payload of a PDU set. A PDU set is composed of one or more PDUs transmitting the payload of an information unit generated at the application level. This information unit may be, for example, at least one of an image frame and a video slice of XR or a media service. The information unit may also be at least one of an I frame, a P frame, and a B frame of video data in a group of pictures (GOP) format. Furthermore, in a multimodal application that handles multiple types of interrelated data, such as XR, each of multiple types of data (e.g., pause information, audio information, video information, haptics, etc.) may be an information unit. Of course, the information units are not limited to these.

[0170] That is, packets in a PDU set are treated as a unit of data to be received and decoded within a certain period of time. For example, a UE may decode an image frame or video slice only if it has successfully received all or a certain amount of packets carrying those packets. For example, a UE may decode an image frame in a GOP only if it has successfully received all dependent image frames.

[0171] 5GS allows for finer granularity in identifying data by PDU sets within QoS flows, which are the finest granularity in terms of QoS control. 5GS can apply PDU set level QoS control in addition to QoS flow level QoS control.

[0172] The PCF 545 can associate information of the AF session with the PDU session. The AF 548 can request that a data session (e.g., a PDU session) for the UE 40 be established as a session with a specific QoS (e.g., low latency or low jitter) via the AF session with the PCF 545.

[0173] The SMF 546 associates PCC rules to QoS flows based on the QoS and service requirements. The SMF 546 assigns a QFI to the new QoS flow and obtains the PCC rules and other information associated with the QoS flow from the PCF 545.

[0174] From this PCC rule, the SMF 546 obtains the QoS profile of the QoS flow, instructions regarding the corresponding UPF 520 (e.g., N4 rule), and QoS rule.

[0175] The base station (gNB) of the RAN / AN 510 can establish at least one DRB (Data Radio Bearer) together with a PDU session with each UE 40. The DRB is a logical path for transmitting data.

[0176] The 5G QoS model supports GBR (Guaranteed flow Bit Rate), which guarantees bandwidth, and Non-GBR (Non-Guaranteed flow Bit Rate), which does not guarantee bandwidth. Furthermore, Delay-critical GBR is supported for TSC (Time Sensitive Communication) QoS flows.

[0177] The RAN / AN 510 and the core network CN ensure quality of service by mapping each packet to the appropriate QoS flow and DRB, i.e., a two-stage mapping is performed: mapping between IP flows and QoS flows in the NAS, and mapping between QoS flows and DRBs in the AS.

[0178] At the NAS level, a QoS flow is characterized by a QoS profile provided from the core network CN to the RAN / AN 510 and a QoS rule provided from the core network CN to the UE 40 .

[0179] The QoS profile is used by the RAN / AN 510 to determine how to handle traffic over the air interface, and the QoS rules are used to instruct the UE 40 on the mapping between user plane traffic in the uplink and QoS flows.

[0180] Therefore, for a multicast MBS (Multicast / Broadcast Service) session, the QoS rules of the MBS QoS flow and the QoS parameters at the QoS flow level are not provided to the UE 40 .

[0181] The QoS profile is provided to the RAN / AN 510 from the SMF 546 via the AMF 541 and reference point N2, or is pre-configured in the RAN / AN 510.

[0182] The SMF 546 may also provide the UE 40 with one or more QoS rules and, if necessary, QoS flow-level QoS parameters associated with the QoS rules via the AMF 541 and the reference point N1.

[0183] Additionally or alternatively, reflective QoS control may be applied to the UE 40. Reflective QoS control is QoS control that monitors the QFI of downlink packets and applies the same mapping to uplink packets.

[0184] A QoS flow can be a GBR QoS flow or a non-GBR QoS flow depending on its QoS profile, which includes QoS parameters such as 5QI (5G QoS Identifier) ​​and ARP (Allocation and Retention Priority).

[0185] The ARP includes information regarding priority level, preemption capability, and preemption vulnerability.

[0186] Priority defines the relative importance of a QoS flow, with the lowest Priority Level indicating the highest priority.

[0187] Preemption capability is a metric that defines whether a QoS flow can seize resources already allocated to other, lower priority QoS flows, while preemption vulnerability is a metric that defines whether a QoS flow can give up its allocated resources to other, higher priority QoS flows.

[0188] Preemption capability and preemption vulnerability can be set to either "enabled" or "disabled."

[0189] Additionally, the QoS profile of a QoS flow may include PDU Set QoS Parameters.

[0190] For a GBR QoS flow, the QoS profile may include, for example, at least one of the following information: GFBR for uplink and downlink; MFBR (Maximum Flow Bit Rate) for uplink and downlink; Maximum Packet Loss Rate for uplink and downlink; Delay Critical Resource Type; and Notification Control.

[0191] In a non-GBR QoS flow, the QoS profile may include at least one of a Reflective QoS Attribute (RQA) and Additional QoS Flow Information.

[0192] The notification control of the QoS parameter indicates whether a notification is required from the RAN / AN 510 when a QoS flow cannot meet the GFBR. If the notification control is "enabled" for a GBR QoS flow and the RAN / AN 510 determines that the GFBR cannot be met, the RAN / AN 510 sends a notification to the SMF 546.

[0193] In this case, the RAN / AN 510 must maintain the GBR QoS flow unless a special condition exists that requires the RAN / AN 510 to release RAN resources for the GBR QoS flow, such as at least one of a radio link failure and RAN internal congestion.

[0194] If it is determined that the GFBR is again satisfied for the QoS flow, the RAN / AN 510 sends a new notification to that effect to the SMF 546.

[0195] An alternative QoS profile can also be used to control the notification of QoS parameters. The alternative QoS profile consists of a set of packet delay budget (PDB), packet error rate (PER), averaging window, and GFBR. The alternative QoS profile for a delay-critical GBR QoS flow can further include information on maximum data burst volume (MDBV).

[0196] When the RAN / AN 510 sends a notification to the SMF 546 that the QoS profile cannot be satisfied, the RAN / AN 510 checks, based on the list of alternative QoS profiles, whether there is a higher-priority alternative QoS profile that can currently satisfy the QoS profile. If there is a corresponding alternative QoS profile, the RAN / AN 510 indicates to the SMF 546 that there is an alternative QoS profile that can currently satisfy the QoS profile. To do this, the RAN / AN 510 includes information referencing the alternative QoS profile in the notification sent to the SMF 546. This control allows the SMF 546 to determine that even the lowest-priority alternative QoS profile cannot satisfy the QoS profile.

[0197] The AMBR (Aggregate Maximum Bit Rate) is related to the Session-AMBR of each PDU session and the UE-AMBR of each UE 40 for each PDU session. The Session-AMBR limits the aggregate bit rate expected to be provided across all Non-GBR QoS flows for a particular PDU session. The Session-AMBR is managed by the UPF 520. The UE-AMBR also limits the aggregate bit rate expected to be provided across all Non-GBR QoS flows for a UE 40. The UE-AMBR is managed by the RAN / AN 510.

[0198] Furthermore, a Slice Maximum Bit Rate (S-MBR) related to the network slice (S-NSSAI) may be set for each UE 40. The S-MBR may be included in the subscriber information as a Subscribed UE-Slice-MBR.

[0199] The UE-Slice-MBR limits the aggregate bit rate expected to be provided across all GBR and non-GBR QoS flows belonging to all PDU sessions established by UE 40 for the same network slice (S-NSSAI).

[0200] RAN / AN 510 receives a UE-Slice-MBR corresponding to the network slice (S-NSSAI) from AMF 541. RAN / AN 510 sets the Session-AMBR and MFBR for UE 40 so that the sum of the Session-AMBR and MFBR of the GBR QoS flow of all PDU sessions belonging to this network slice (S-NSSAI) is the UE-Slice-MBR.

[0201] The 5QI is related to QoS features. It provides guidelines (policies) for setting node-specific parameters for each QoS flow. A communication device can learn standardized or pre-configured 5G QoS features from the 5QI. Standardized or pre-configured 5G QoS features are not explicitly signaled. Signaled QoS features can be part of a QoS profile.

[0202] The QoS characteristics may include information regarding at least one of a resource type, a priority, a packet delay tolerance, a packet error rate, an averaging window, and a maximum data burst volume.

[0203] The resource type is a GBR QoS flow, a non-GBR QoS flow, or a delay-critical GBR QoS flow. The packet delay tolerance may include a packet delay tolerance in the core network CN.

[0204] At the AS level, DRB defines how packets are handled on the radio interface (Uu interface). DRB provides uniform packet forwarding treatment for any packet.

[0205] The RAN / AN 510 maps QoS flows to DRBs based on the QFI and the QoS profile configured for that QFI. The RAN / AN 510 can establish different DRBs for packets requiring different packet forwarding treatments (see FIG. 9).

[0206] The RAN / AN 510 can also multiplex multiple QoS flows belonging to the same PDU session onto the same DRB (see FIG. 9).

[0207] In the uplink, the mapping of QoS flows to DRBs is controlled by mapping rules, which are signaled in two different ways:

[0208] One method is called Reflective Mapping, in which UE 40 monitors the QFI of downlink packets for each DRB and applies the same mapping to uplink packets.

[0209] The other method is called explicit configuration, in which the mapping rule of QoS flows to DRBs is explicitly signaled by RRC (Radio Resource Control).

[0210] In the downlink, the QFI is signaled by the RAN / AN 510 over the Uu interface for Reflective Quality of Service (RQoS). However, neither the RAN / AN 510 nor the NAS signals the QFI for a DRB over the Uu interface unless they use reflective mapping for the QoS flows carried on that DRB.

[0211] In the uplink, the RAN / AN 510 can configure signaling of QFI to the UE 40 on the Uu interface. The RAN / AN 510 can also configure a default DRB for each PDU session. If an uplink packet does not fit either the explicit configuration or the reflective mapping, the UE 40 maps the packet to the default DRB of the PDU session.

[0212] For Non-GBR QoS flows, the core network CN may send additional QoS flow information parameters associated with any QoS flow to the RAN / AN 510 to indicate an increased frequency of some traffic compared to other Non-GBR QoS flows within the same PDU session.

[0213] How multiple QoS flows within a PDU session are mapped to one DRB is up to the RAN / AN 510. For example, the RAN / AN 510 may map a GBR QoS flow and a non-GBR QoS flow to the same DRB or to separate DRBs. The RAN / AN 510 may also map multiple GBR QoS flows to the same DRB or to separate DRBs.

[0214] In 5G NR, a new SDAP (Service Data Adaptation Protocol) sublayer is introduced for QoS control via QoS flows. The SDAP sublayer maps QoS flow traffic to an appropriate DRB. The SDAP sublayer can have multiple SDAP entities. The SDAP sublayer has an SDAP entity for each PDU session on the Uu interface. The establishment or release of an SDAP entity is performed by RRC.

[0215] QoS flows are identified by a QFI in the PDU session container contained in the GPRS Tunneling Protocol (GTP)-U header. PDU sessions are identified by a GTP-U Tunnel Endpoint ID (TEID). The SDAP sublayer maps each QoS flow to a specific DRB.

[0216] In addition, to support PDU set-based QoS control, the PSA (PDU Session Anchor)-UPF 520 identifies PDUs belonging to a PDU set, determines PDU set information, and transmits the PDU set information in a GTP-U header to the RAN / AN 510. The PDU set information is used by the RAN / AN 510 for PDU set-based QoS control.

[0217] The PDU set information may include, for example, at least one of the following information: PDU set sequence number; Indication of the End PDU of the PDU set; PDU sequence number within the PDU set; PDU set size in bytes; Importance of the PDU set.

[0218] Here, the RAN / AN 510 can identify the relative importance of a PDU set relative to other PDU sets within the QoS flow based on the importance of the PDU set. Furthermore, information required to identify the PDU set is provided from the SMF 546 to the PSA-UPF 520. This information is provided using the Protocol Description of the Packet Detection Rule (PDR), which is one of the N4 rules described below.

[0219] Upon receiving a QoS monitoring request from the AF 548, the PCF 545 generates an authorized QoS monitoring policy and provides it to the SMF 546. At this time, the PCF 545 may include the QoS monitoring policy in a PCC rule. Note that the AF 548 may include the QoS monitoring request in an AF request (described later).

[0220] Here, the AF 548 can request monitoring of packet delay, monitoring of congestion information, monitoring of data rate, monitoring of QoS notification, and the like as QoS monitoring.

[0221] The monitoring of packet delay is the measurement of UL (Uplink) packet delay, DL (Downlink) packet delay, or RT (Round Trip) packet delay between the UE 40 and the PSA-UPF 520 .

[0222] The congestion information monitoring is monitoring of congestion information related to UL and / or DL ​​QoS flows provided by the RAN / AN 510.

[0223] Data rate monitoring is the measurement of UL and / or DL ​​data rates for each QoS flow.

[0224] QoS notification monitoring is monitoring of notification control information of QoS parameters provided by the RAN / AN 510 .

[0225] Furthermore, the PCF 545 is provided with information about the periodicity from the AF 548 as information related to the traffic pattern for the TSC QoS flow. In this case, the PCF 545 can include the information about the periodicity in the PCC rule. Furthermore, the PCF 545 may include, in the PCC rule, an indication to perform traffic parameter measurements to detect jitter occurring at N6 and to measure the UL periodicity and / or DL ​​periodicity in accordance with a local policy. The PCF 545 may then transmit the PCC rule including this indication to the SMF 546. 5GS can also treat these measurements as QoS monitoring.

[0226] The SMF 546 can activate end-to-end UL / DL / RT packet delay measurements for QoS flows between the UE 40 and the PSA-UPF 520. The SMF 546 can perform this activation during the PDU session establishment procedure or during the PDU session modification procedure.

[0227] The SMF 546 sends a QoS monitoring request to the UPF 520 via reference point N4, and then sends N2 signaling to request QoS monitoring between the UPF 520 and the RAN / AN 510.

[0228] The SMF 546 requests QoS monitoring based on the QoS monitoring policy received from the PCF 545 or a pre-configured locally authorized QoS monitoring policy. The QoS monitoring request includes monitoring variables determined by the SMF 546.

[0229] The RAN / AN 510 measures the delay of UL / DL packets in the RAN / AN 510. The RAN / AN 510 provides the measurement results to the UPF 520 via reference point N3.

[0230] The UPF 520 calculates the delay of UL / DL packets at the reference point N3 or N9. The UPF 520 sends the QoS monitoring result to the SMF 546 based on a predetermined condition, such as one-time, periodic, or event-triggered.

[0231] Furthermore, the UPF 520 may transmit the QoS monitoring results to the AF 548 via the locally deployed NEF 542. Here, the QoS monitoring results are, for example, as follows: Measurement results of the bit rate (e.g., average bit rate, maximum bit rate) of each GBR QoS flow of the target PDU session Measurement results of the total bit rate of all Non-GBR QoS flows of the target PDU session Measurement results of the packet error rate of the target PDU session Measurement results of the total bit rate of all Non-GBR QoS flows of the target UE 40 Measurement results of the packet error rate of the target UE 40 Measurement results of the UL / DL packet delay

[0232] The AF 548 may also transmit a request for monitoring and reporting packet delay variation together with the request for measuring packet delay to the PCF 545. Here, the packet delay variation is, for example, the variation in packet delay measured between the UE 40 and the PSA-UPF 520. The packet delay variation is one definition for evaluating jitter during packet transmission.

[0233] The packet delay variation request may include, for example, at least one of the following: - Packet delay variation parameter to be measured (UL, DL, or Round Trip (RT) packet delay variation) - Reporting frequency (event triggered or periodic)

[0234] In response to a packet delay variation monitoring request from the AF 548, the PCF 545 initiates a QoS monitoring process. The PCF 545 obtains the UL, DL, or RT (Round Trip) QoS monitoring results from the SMF 546. The PCF 545 derives 5GS packet delay variation based on the QoS monitoring results and reports it to the AF 548.

[0235] The delay of the UL / DL packet is a delay including the delay of the UL / DL packet in the RAN / AN 510 portion obtained from the RAN / AN 510 and the delay of the UL / DL packet at the reference point N3 or N9.

[0236] Also, if the PDU session is a session via a TSN bridge, the packet delay allowable time for the TSC QoS flow is the sum of the 5G-AN PDB (Packet Delay Budget) and the CN (Core Network) PDB.

[0237] The above-described QoS monitoring mechanism can also be applied to TSC QoS flows to measure bit rates (e.g., average bit rate, maximum bit rate) between UE 40 and PSA-UPF 520 and to measure end-to-end UL / DL packet delays.

[0238] TSC QoS flows use a resource type of Delay-critical GBR and TSC Assistance Information. TSC QoS flows can use standardized 5QI, pre-configured 5QI, or dynamically assigned 5QI values.

[0239] For a TSC QoS flow, it is required to transmit one data burst with the maximum data burst amount within the 5G-AN PDB. The TSC Burst Size is used to set the maximum data burst amount. The maximum TSC burst size is treated as the maximum amount of data within a period equal to the 5G-AN PDB value of 5QI. The maximum value of the TSC burst size is mapped to a 5QI with an equal or larger maximum data burst amount.

[0240] PDU Set QoS Parameters are used to support PDU Set based QoS Handling. PDU Set specific QoS characteristics include at least one of the following: PDU Set Delay Budget (PSDB), PDU Set Error Rate (PSER), and PDU Set Integrated Handling Information (PSIHI).

[0241] The PCF 545 determines the PDU set QoS parameters according to the information provided by the AF 548 and / or local configuration. The PDU set QoS parameters are sent to the SMF 546 as part of the PCC rules. The SMF 546 sends the PDU set QoS parameters to the RAN / AN 510 as part of a QoS profile.

[0242] The PDU Set Delay Tolerance defines the upper limit of the delay that occurs when transmitting a PDU set between the UE 40 and the termination point of the N6 interface of the UPF 520. In other words, the PDU Set Delay Tolerance is the time from receiving the first PDU of a PDU set to successfully receiving all PDUs. The PDU Set Delay Tolerance applies to the DL PDU set received by the PSA-UPF 520 via the N6 interface and the UL PDU set transmitted by the UE 40.

[0243] The PDU set error rate defines an upper limit on the ratio of PDU sets not successfully received by a higher layer (e.g., the PDCP sublayer of the RAN / AN 510) to PDU sets processed by the link layer (e.g., the RLC sublayer of the RAN / AN 510). One QoS flow is associated with only one PDU set error rate. The packet error rate value is the same for UL and DL. If a PDU set error rate is available, its use is preferred over the packet error rate.

[0244] The PDU set aggregation processing information indicates whether or not all PDUs in the PDU set are necessary for the application layer on the receiving side that uses the PDU set.

[0245] Here, the notification control of QoS parameters and alternative QoS profiles described above may also be applied to this PDU set QoS parameters.

[0246] <3-4. Network slice selection support information> A network slice is a unit of service obtained by dividing communication services provided by 5G according to the communication characteristics of each service (e.g., data rate, delay, etc.).

[0247] Each network slice is assigned Single Network Slice Selection Assistance Information (S-NSSAI) as Network Slice Selection Assistance Information (NSSAI). The network slice selection assistance information is information for assisting in the selection of a network slice. The S-NSSAI is composed of a mandatory 8-bit SST (Slice / Service Type) that identifies the slice type, and an optional 24-bit SD (Slice Differentiator) that distinguishes different slices within the same SST.

[0248] The S-NSSAI can use either a standardized SST or a non-standardized proprietary SST. When a standardized S-NSSAI value is used, it contains only the standardized SST without the SD. On the other hand, when a non-standardized S-NSSAI value is used, it contains the standardized SST and SD, or the non-standardized SST and SD, or the non-standardized SST only. A non-standardized S-NSSAI value can only be used within the PLMN, i.e., the telecom operator, that uses it.

[0249] FIG. 10 is a diagram showing standardized SST values. The table shown in FIG. 10 is based on the table shown in 3GPP TS23.501. The above-mentioned "when standardized S-NSSAI values ​​are used" corresponds to the case where S-NSSAI values ​​including only these SST values ​​(eMBB: 1, URLLC: 2, MIoT: 3, V2X: 4, HMTC: 5, HDLC: 6) are used. In other words, for other network slices, for example, for network slices subdivided by SD, non-standardized S-NSSAI values ​​are used.

[0250] The network slice configuration information includes one or more Configured NSSAI(s). A serving PLMN (Serving Public Land Mobile Network) can configure a Configured NSSAI that applies to each PLMN in the UE 40. Alternatively, a Home PLMN (HPLMN) can configure a Default Configured NSSAI in the UE 40. Only when a Configured NSSAI for the serving PLMN is configured in the UE 40, the UE 40 under the serving PLMN can use the Default Configured NSSAI.

[0251] Note that a Default Configured NSSAI may be set in advance in the UE 40. Furthermore, the UDM 547 of the HPLMN may provide or update the Default Configured NSSAI using a UE Parameters Update via a UDM Control Plane process.

[0252] A Configured NSSAI consists of one or more S-NSSAI(s).

[0253] The Requested NSSAI is the NSSAI provided by the UE 40 to the serving PLMN during the registration process. The Requested NSSAI must be one of the following: Default Configured NSSAI Configured NSSAI Allowed NSSAI or a part of it NSSAI that is the Allowed NSSAI or a part of it plus one or more S-NSSAIs included in the Configured NSSAI

[0254] The Allowed NSSAI is, for example, the NSSAI that the serving PLMN provides to the UE 40 during the registration process. The Allowed NSSAI indicates one or more S-NSSAI(s) values ​​that can be used within the current registration area of ​​the current serving PLMN.

[0255] The Rejected S-NSSAI indicates the value of one or more S-NSSAIs included in the Requested NSSAI that is not authorized for use in at least one tracking area within the current registration area of ​​the current serving PLMN.

[0256] Here, a tracking area is an area used for mobility management and is identified by a Tracking Area Identity (TAI). The network (PLMN) manages the location of the UE 40 within a set of tracking areas in which the UE 40 is camped so that messages or data can be transmitted to the UE 40 in the RRC_IDLE state. When the UE 40 is registered in the network, the AMF 541 assigns a set of tracking areas included in the TAI list as an area in which the UE 40 is registered (a registration area). In other words, the network manages that the registered UE 40 is located within any of the tracking areas in the TAI list.

[0257] If UE 40 detects a more optimal cell according to the cell reselection criteria, it reselects the cell and camps on it. At this time, if the selected cell does not belong to any tracking area in the TAI list in which UE 40 is registered, a location registration process, i.e., a process of updating the TAI list, is performed.

[0258] The Subscribed S-NSSAI is an S-NSSAI that UE 40 can use within the PLMN according to the subscription information. The subscription information must include one or more Subscribed S-NSSAIs and at least one default S-NSSAI.

[0259] The UDM 547 transmits a maximum of 16 Subscribed S-NSSAIs to the AMF 541. Therefore, the number of S-NSSAIs that can be included in the Configured NSSAI is 16. The contract information that the UDM 547 transmits to the AMF 541 must include at least one default S-NSSAI. The NSSF 544 determines the Allowed NSSAI and the Configured NSSAI, and determines an AMF Set, which is a list of candidates for the AMF 541. For example, an AMF 541 may be selected from the list of candidates according to the network slice used by the UE 40 or other criteria, and the UE 40 may be assigned to the selected AMF 541.

[0260] One or more S-NSSAI(s) included in the Allowed NSSAI(s) provided to the UE 40 may contain values ​​that are not part of the UE 40's current network slice configuration information for the serving PLMN. In this case, the network provides a mapping between each S-NSSAI in the Allowed NSSAI and a corresponding S-NSSAI in the HPLMN for the Allowed NSSAI. This mapping information allows the UE 40 to associate applications with the S-NSSAI in the HPLMN and the corresponding S-NSSAI in the Allowed NSSAI per Network Slice Selection Policy (NSSP) in a UE Route Selection Policy (URSP) rule or per the UE 40's local configuration.

[0261] For example, if the HPLMN and / or VPLMN (Visitor PLMN) uses a non-standardized S-NSSAI value, UE 40 needs to provide information regarding the mapping between the S-NSSAI value included in the Requested NSSAI and the corresponding S-NSSAI value used in the HPLMN when roaming. UE 40 may obtain this mapping information in advance from the serving PLMN as a mapping between the S-NSSAI value included in the Configured NSSAI for the serving PLMN and the corresponding S-NSSAI value used in the HPLMN. Alternatively, UE 40 may obtain this mapping information in advance from the serving PLMN as a mapping between the S-NSSAI value included in the Allowed NSSAI for the serving PLMN and the corresponding S-NSSAI value used in the HPLMN.

[0262] Furthermore, the UE 40 can support a contract-based restriction function regarding network slices that can be simultaneously registered. If the UE 40 supports this function, the UE 40 includes, as part of the UE 5GMM Core Network Capability, information indicating that the function is supported in a registration request message at the time of initial registration and mobility registration update.

[0263] The AMF 541 provides a Configured NSSAI to the UE 40 that has notified that it supports the contract-based restriction function regarding simultaneously registered network slices. At this time, the AMF 541 provides information regarding the Network Slice Simultaneous Registration Group (NSSRG) associated with the network slice (S-NSSAI(s)) of the HPLMN.

[0264] The contract information including the NSRRG information must include at least one default S-NSSAI. If multiple default S-NSSAIs are configured, the default S-NSSAIs are associated with the same NSRRG. In other words, the UE 40 is allowed to register all the default S-NSSAIs simultaneously.

[0265] The HPLMN can transmit, as subscription information, other Subscribed S-NSSAIs that share at least all NSSRGs defined for the default S-NSSAI, in addition to the default S-NSSAI, to the VPLMN. In this case, the HPLMN does not need to transmit NSRRG information to the VPLMN.

[0266] A UE 40 that receives an NSSRG must include only network slices (S-NSSAIs) assigned to the same common NSSRG in the Requested NSSAI.

[0267] Furthermore, when the boundary of the service area of ​​the network slice does not coincide with the boundary of the tracking area, the communication device can define additional constraints on the use of the network slice within the tracking area using network slice availability location information (S-NSSAI location availability information). For example, consider a case where the S-NSSAI of the Configured NSSAI is not available in some cells within the tracking area of ​​the Registration Area. In this case, the network slice availability location information including location information (e.g., cell ID) of a cell in which the S-NSSAI is available among multiple cells within the tracking area is provided to the UE 40.

[0268] The AMF 541 may determine the Target NSSAI by itself or in cooperation with the NSSF 544. The Target NSSAI is information used by the RAN / AN 510 (e.g., NG-RAN) to redirect the UE 40 to cells / tracking areas of other frequency bands that support the S-NSSAI of the Target NSSAI and to other tracking areas. The RAN / AN 510 uses this information in addition to information such as the Allowed NSSAI and the RFSP (RAT / Frequency Selection Priority) for the Allowed NSSAI to redirect the UE 40.

[0269] The Target NSSAI includes at least one S-NSSAI in the Requested NSSAI. For example, the Target NSSAI includes at least one S-NSSAI that is not available in the current tracking area but is available in another tracking area in another frequency band or in an area in another frequency band that overlaps with the current tracking area. Furthermore, at least one S-NSSAI in the Requested NSSAI may be optionally added to the Target NSSAI. For example, the S-NSSAI added as an option is an S-NSSAI that is not available in the current tracking area but is available in the same tracking area as the tracking area in which the S-NSSAI included in the Target NSSAI is available.

[0270] The AMF 541 obtains an RFSP index (RAT / Frequency Selection Priority Index) suitable for the Target NSSAI from the PCF 545. Then, the AMF 541 includes the RFSP index in information to be sent to the RAN / AN 510 (e.g., NG-RAN). If the PCF 545 is not installed, the AMF 541 determines the RFSP index according to a locally configured rule. The RAN / AN 510 maps the RFSP index to a locally defined configuration to apply an individual radio resource management policy taking into account the available information. That is, the RAN / AN 510 can select a configuration for a radio resource management policy suitable for the Target NSSAI corresponding to the RFSP index.

[0271] If the RAN / AN 510 can redirect the UE 40 to a new tracking area that supports the Target NSSAI or an S-NSSAI of either the Target NSSAI, the RFSP index associated with the Target NSSAI is considered, otherwise the RFSP index of the Allowed NSSAI is considered.

[0272] In addition, a partial network slice can be provided within a registration area by configuring a Partially Allowed NSSAI and / or an S-NSSAI that is partially rejected within the registration area (S-NSSAIs rejected partially in the RA).

[0273] The S-NSSAI of an Allowed NSSAI can be used in all tracking areas within the registration area, whereas the S-NSSAI of a Partially Allowed NSSAI can only be used in tracking areas corresponding to the list of tracking areas associated with that S-NSSAI.

[0274] Assume that UE 40 supports partial network slicing within the registration area. In this case, AMF 541 configures a registration area for UE 40, taking into account the support status of the S-NSSAI of the Requested NSSAI in the current tracking area and surrounding tracking areas. AMF 541 provides the Partially Allowed NSSAI or the S-NSSAI that is partially rejected within the registration area to UE 40 using a Registration Accept message or a UE Configuration Update Command message.

[0275] For each S-NSSAI of the Partially Allowed NSSAI, the AMF 541 provides a list of tracking areas in which the S-NSSAI is supported. Alternatively, the AMF 541 may reject the S-NSSAI with a rejection reason indicating "partially in the RA". For each S-NSSAI of the partially rejected S-NSSAI in the registration area, the AMF 541 provides a list of tracking areas in which the S-NSSAI is supported or not supported.

[0276] If the S-NSSAI is unavailable or is overloaded, a Network Slice Replacement function may be used to replace the S-NSSAI with an Alternative S-NSSAI.

[0277] The AMF 541 can decide to replace the S-NSSAI with an Alternative S-NSSAI based on a notification from the NSSF 544, the PCF 545, or the OAM (Operations, Administration and Maintenance).

[0278] In the case of roaming, to initiate network slice substitution of the HPLMN's S-NSSAI, the V-AMF 541-2 can receive notification of network slice availability of the HPLMN's S-NSSAI from the HPLMN's H-NSSF 544-1 via the V-NSSF 544-2 of the VPLMN.

[0279] The AMF 541 determines an Alternative S-NSSAI for the UE 40 that has registered the S-NSSAI based on a notification from the NSSF 544 or the PCF 545 (or based on a local configuration if the NSSF 544 or the PCF 545 does not provide an Alternative S-NSSAI).

[0280] The Alternative S-NSSAI must be supported within the registration area of ​​the UE 40. For example, assume that the AMF 541 cannot determine the Alternative S-NSSAI for the S-NSSAI because the NSSF 544 or the PCF 545 does not provide the Alternative S-NSSAI. In this case, the AMF 541 may further negotiate with the PCF 545 to determine the Alternative S-NSSAI.

[0281] The UE 40 notifies the network of its support for the network slice alternative function during the registration process. The PDU session related to the S-NSSAI that needs to be exchanged supports the UE 40 in connected mode (CM-CONNECTED mode) existing in the UE context. To enable this, the AMF 541 provides the UE 40 with an Alternative S-NSSAI for this S-NSSAI, which is included in the Allowed NSSAI and the Configured NSSAI. The AMF 541 may also provide the UE 40 with mapping information between the S-NSSAI and the Alternative S-NSSAI using a UE Configuration Update message.

[0282] After sending the mapping information to the UE 40, the AMF 541 invokes the Update Session Management Context (Nsmf_PDUSession_UpdateSMContext) service for the current PDU session associated with the S-NSSAI exchanged for the Alternative S-NSSAI, and instructs the SMF 546 to update the PDU session required to transition the PDU session to the Alternative S-NSSAI.

[0283] The UE 40 establishes a Non-Access Stratum (NAS) signaling connection through a Service Request procedure or a UE registration procedure. At this time, it is assumed that the AMF 541 decides to exchange S-NSSAIs to support the UE 40 in the CM-IDLE state. At this time, if a PDU session related to the S-NSSAI exists in the UE context, the AMF 541 provides the UE 40 with mapping information between the S-NSSAI and the Alternative S-NSSAI using a UE Configuration Update message or a Registration Accept message.

[0284] <<4. Basic Operation of Communication System>> A specific configuration example of the communication system 1 has been described above. Before describing the operation of the communication system 1 that solves the problem of this embodiment, the basic operation of the communication system 1 will be described.

[0285] In the following description, the communication system 1 is assumed to be 5GS (for example, 5GS shown in FIGS. 7 to 10) as an example. However, the communication system 1 is not limited to 5GS. The communication system 1 may be 4GS or 6GS. Of course, the communication system 1 may be any other wireless communication system.

[0286] Session Establishment Processing> First, the session establishment processing will be described. Fig. 11 is a diagram showing an example of a connection processing in 5GS.

[0287] During communication, UE 40 transitions to the RRC_IDLE and CM-IDLE states (step S101). UE 40 in the RRC_IDLE and CM-IDLE states performs cell reselection (step S102) and camps on an appropriate cell that meets predetermined criteria.

[0288] UE 40 determines to use an S-NSSAI corresponding to the application to be used from among the Allowed NSSAIs (step S103). Subsequently, UE 40 transmits an RRC Setup Request message to RAN / AN 510 of the base station that manages the cell where UE 40 is camped (step S104).

[0289] Upon receiving this, RAN / AN 510 transmits an RRC Setup message to UE 40 (step S105). UE 40 transitions to an RRC_CONNECTED and CM-IDLE state (step S106) and returns an RRC Setup Complete message to RAN / AN 510 (step S107). This completes the RRC setup process.

[0290] Next, the UE 40 transmits a PDU SESSION ESTABLISHMENT REQUEST message, which is a NAS message, to the AMF 541 (step S108). As a result, a PDU session establishment process is executed between the UE 40 and the DN 530 via the RAN / AN 510 and the UPF 520 (step S109).

[0291] The UE 40 transitions to an RRC_CONNECTED and CM-CONNECTED state (step S110). Note that the PDU SESSION ESTABLISHMENT REQUEST message can include the S-NSSAI selected by the UE 40.

[0292] The AMF 541 sends an INITIAL CONTEXT SETUP REQUEST message to the RAN / AN 510 (step S111). The INITIAL CONTEXT SETUP REQUEST message may include at least one of a PDU session context, a security key, a UE radio capability, and a UE security capability. The INITIAL CONTEXT SETUP REQUEST message may also include an Allowed NSSAI. The INITIAL CONTEXT SETUP REQUEST message may also include an S-NSSAI for each PDU session.

[0293] The RAN / AN 510 sets a UE context for the UE 40 and transmits a SecurityModeCommand message to the UE 40 (step S112). The SecurityModeCommand message includes an integrity algorithm selected by the RAN / AN 510.

[0294] The UE 40 verifies the integrity of the received SecurityModeCommand message to confirm the validity of the message, and returns a SecurityModeComplete message to the RAN / AN 510 (step S113).

[0295] The RAN / AN 510 transmits an RRCReconfiguration message to the UE 40 in order to set up a Signaling Radio Bearer (SRB) 2 and a Data Radio Bearer (DRB) (step S114). The UE 40, having received this message, returns an RRCReconfigurationComplete message to the RAN / AN 510 (step S115). As a result, the SRB 2 and the DRB are established between the UE 40 and the RAN / AN 510.

[0296] The RAN / AN 510 sends an INITIAL CONTEXT SETUP REQUEST RESPONSE message to the AMF 541 to notify that the UE context configuration process has been completed (step S116).

[0297] 12A and 12B are diagrams showing an example of a PDU session establishment process. Specifically, FIG. 12A and 12B are diagrams showing an example of a PDU session establishment process in step S109 of FIG. 11, which is started by a PDU SESSION ESTABLISHMENT REQUEST message.

[0298] When the AMF 541 receives a PDU session establishment request message from the UE 40 (step S108 shown in FIGS. 11 and 12A), it performs SMF selection (step S201 shown in FIG. 12A).

[0299] The AMF 541 sends an Nsmf_PDUSession_Create_SMContext Request message to the selected SMF 546 (step S202). The Nsmf_PDUSession_Create_SMContext Request message includes a Subscription Permanent Identifier (SUPI), an S-NSSAI, and a UE Requested DNN or DNN.

[0300] If session management subscription data corresponding to the SUPI, S-NSSAI, and DNN is not available, the SMF 546 uses a Nudm_SDM_Get message to acquire the session management subscription data from the UDM 547. In addition, the SMF 546 registers the session management subscription data with the UDM 547 using a Nudm_SDM_Subscribe message so that it can be notified when the session management subscription data is updated.

[0301] Upon receiving the Nsmf_PDUSession_Create_SMContext Request message, the SMF 546 creates an SM context if it can process the message. The SMF 546 returns an Nsmf_PDUSession_Create_SMContext Response message including an SM context ID to the AMF 541 (step S203).

[0302] If it is necessary to perform a second authentication and authorization process by the DN-AAA server during the PDU session establishment process, the SMF 546 initiates PDU Session Authentication / Authorization (step S204).

[0303] The SMF 546 performs PCF selection if dynamic policy and charging control (PCC) is applied to the PDU session to be established (step S205). Alternatively, the SMF 546 may apply a local policy.

[0304] In addition, the SMF 546 may perform an SM Policy Association Establishment Procedure to establish an SM Policy Association with the PCF 545 and obtain a default PCC rule for the PDU session (step S206). This allows the PCC rule to be obtained before selecting the UPF 520.

[0305] The SMF 546 performs UPF selection (step S207) according to a preset rule or the PCC rule acquired in step S206. As a result, the SMF 546 selects one or more UPFs 520. The SMF 546 transmits an N4 Session Establishment Request message to the selected UPF 520 (step S208).

[0306] The N4 session establishment request message is used to set an N4 rule for controlling uplink and downlink traffic in the UPF 520. The N4 rule is information related to, for example, a packet detection rule (PDR), a forwarding action rule (FAR), a QoS enforcement rule (QER), a usage reporting rule (URR), and a buffering action rule (BAR).

[0307] The PDR contains information necessary for classifying packets in the UPF 520. The FAR contains information regarding how to handle a particular packet, such as forward, duplicate, drop, or buffer. The QER contains information regarding an indication of the QoS to be applied to the traffic. The URR contains information necessary for traffic metering and reporting. The BAR contains information regarding how long and how much data will be buffered and how to notify the control plane.

[0308] The SMF 546 may also send the aforementioned QoS monitoring request to the UPF 520 via an N4 session establishment request message.

[0309] The SMF 546 may also send a request to the UPF 520 to detect the last PDU of each data burst for the TSC QoS flow according to the PCC rules and / or local policies. In this case, the SMF 546 may send the request via an N4 session establishment request message. Details of the data burst will be described later.

[0310] Upon receiving a request to detect the last PDU, the UPF 520 detects the last PDU of each data burst and marks the GTP-U header of the last PDU of the downlink as "End of Data burst".

[0311] The UPF 520 that has received the N4 session establishment request returns an N4 session establishment response message to the SMF 546 (step S209). Note that, in the above step S207, if multiple UPFs 520 are selected for the PDU session, the N4 session establishment process is initiated for each UPF 520.

[0312] The SMF 546 sends a Namf_Communication_N1N2MessageTransfer message to the AMF 541 (step S210). The Namf_Communication_N1N2MessageTransfer message may include at least one of a PDU session ID, N2SM information, CN tunnel information, S-NSSAI, and an N1SM container.

[0313] The N2SM information may include at least one of a PDU session ID, a QFI, and a QoS profile.

[0314] If multiple UPFs 520 are used for a PDU session, the CN tunnel information includes tunneling information related to these multiple UPFs 520 terminating at N3.

[0315] The N1SM container includes a PDU Session Establishment Accept and QoS rules that the AMF 541 must provide to the UE 40. The PDU Session Establishment Accept includes an S-NSSAI.

[0316] The Namf_Communication_N1N2MessageTransfer message includes a PDU session ID so that AMF541 knows which access to use for UE40.

[0317] 12B, AMF 541 sends an N2 PDU Session Request message to RAN / AN 510 (step S211). The N2 PDU Session Request message includes a NAS message including a PDU session ID and an N1SM container destined for UE 40, and the N2SM information received from SMF 546.

[0318] RAN / AN 510 acquires the PDU session ID, QFI, QoS profile, etc. from the N2SM information included in the N2 PDU session request message. RAN / AN 510 also transfers the NAS message included in the N2 PDU session request message to UE 40 (step S212). As described above, the NAS message includes the PDU session ID and an N1SM container, and the N1SM container includes a PDU session establishment permission and a QoS rule.

[0319] The RAN / AN 510 also assigns AN tunnel information (AN Tunnel Info) to the PDU session. Here, the AN tunnel information includes the tunnel endpoints of each participating RAN / AN node and the QFIs assigned to each tunnel endpoint. The RAN / AN 510 updates N2SM information for notification to the SMF 546. Here, the N2SM information may include at least one of a PDU session ID, AN tunnel information, a list of allowed or denied QFI(s), and a User Plane Enforcement Policy Notification.

[0320] The RAN / AN 510 returns an N2 PDU Session Response message including the N2SM information to the AMF 541 (step S213).

[0321] The AMF 541 acquires the N2SM information through the N2 PDU session response received from the RAN / AN 510. Then, the AMF 541 forwards an Nsmf_PDUSession_UpdateSMContext Request message including the SM context ID and the acquired N2SM information to the SMF 546 (step S214).

[0322] The SMF 546 initiates an N4 session modification procedure between the SMF 546 and the UPF 520. Then, the SMF 546 sends an N4 session modification request message to the UPF 520 (step S215). The SMF 546 provides the UPF 520 with AN tunnel information in addition to the forwarding rule.

[0323] The SMF 546 may also send the aforementioned QoS monitoring request to the UPF 520 via an N4 session modification request message.

[0324] The UPF 520 returns an N4 Session Modification Response message to the SMF 546 (step S216). Note that, when multiple UPFs 520 are used in the PDU session, the session modification process is performed on all UPFs 520 terminating N3.

[0325] The above processing completes the PDU session establishment processing shown in step S109 of FIG.

[0326] <4-2. Association Between AF Request and PCF> Next, association between AF request and PCF will be described.

[0327] The AF 548 can make requests to the 5GS regarding the routing of traffic to or from the application server 10 using an AF request (Application Function Request).

[0328] For example, 5GS can consider the AF request in the selection / reselection of the UPF 520 and / or the SMF 546. The AF request is sent to the PCF 545 via the NEF 542. However, if the AF 548 has direct access to the PCF 545, the AF request is sent to the PCF 545 via a reference point N5 defined between the AF 548 and the PCF 545. The PCF 545 translates the received AF request into policies / rules to be applied to the PDU session.

[0329] The AF request must include the mandatory Traffic Description, Target UE Identifier(s), and AF Transaction Identifier.

[0330] The traffic description is information for identifying traffic, and includes a set of a DNN (Data Network Name) and an S-NSSAI, as well as an application identifier or traffic filtering information.

[0331] The DNN corresponds to the APN (Access Point Name) used in systems prior to 4G. The S-NSSAI is information for assisting in the selection of a network slice (network slice selection support information).

[0332] The application identifier is information for identifying an application that handles user plane traffic. The application identifier is used by the UPF 520 to identify application traffic. The traffic filtering information is information for classifying traffic. The traffic filtering information is, for example, a 5-tuple consisting of a source IP, a source port number, a destination IP, a destination port number, and a protocol number.

[0333] The AF request may also include, depending on the condition, information on the locations of potential applications, where the information on the locations of potential applications is provided as a list including DNAIs (Data Network Access Identifiers) for identifying user plane access to one or more DNs 530 that are candidates for implementing the application.

[0334] Furthermore, the AF request may optionally include at least one of the following information: Spatial Validity Condition, N6 Traffic Routing requirements, Application Relocation Possibility, UE IP address preservation indication, Temporary Validity Condition, Information on AF subscription for SMF events, Information for IP Replacement of Edge Application Server (EAS) in the core network CN, User Plane Latency Requirement, Information on AF change, and Instruction for Edge Application Server relocation (EAS Relocation).

[0335] The Spatial Validity Condition is provided in the form of a valid area. If the AF request is a request regarding traffic routing decision in the SMF 546, the Spatial Validity Condition indicates that the routing applies only to traffic of UEs 40 located at a specific location. If the AF request is a request to register for notification of a user plane path management event, the Spatial Validity Condition indicates that the notification applies only to traffic of UEs 40 located at a specific location.

[0336] Information on N6 traffic routing requirements is information provided for each DNAI. The information on N6 traffic routing requirements may include a routing profile ID and N6 traffic routing information. Here, N6 is a reference point between the UPF 520 and the DN 530. The routing profile ID is identification information for referencing a routing policy pre-agreed between the AF 548 and the core network CN. The N6 traffic routing information includes information required to forward traffic to the DNAI.

[0337] Application Relocation Possibility is information indicating whether an application can be relocated after its location is selected by the core network CN.

[0338] The UE IP address preservation indication indicates that the IP address of the UE 40 related to the traffic identified by the Traffic Description should be preserved. Upon receiving this indication from the AF 548, the core network CN preserves the IP address of the UE 40 by avoiding reselection of the UPF 520 after the UPF 520 has been selected.

[0339] The Temporary Validity Condition is provided in a format that indicates the time interval or period during which the AF request applies. If the AF request is a request regarding a traffic routing decision in the SMF 546, the Temporary Validity Condition indicates when the routing applies. If the AF request is a request to register for notification of a user plane path management event, the Temporary Validity Condition indicates when the notification occurs.

[0340] The AF request, which includes information about the AF subscription for the SMF event, is a request to register for notifications of changes in the user plane path related to the traffic identified by the Traffic Description. This request includes the subscription type, a notification target address for receiving event notifications, etc. If the subscription type is Early Notification, the SMF 546 sends a notification of the path change before a new user plane path is established. If the subscription type is Late Notification, the SMF 546 sends a notification of the path change after a new user plane path is established.

[0341] The information for IP replacement of edge application servers indicates the identifiers of the source edge application server and the target edge application server for edge computing services, such as the IP addresses and port numbers of the source and target edge application servers.

[0342] The User Plane Latency Requirement is a delay in the user plane that is taken into account when relocating a target edge application server. The AF 548 can request the User Plane Latency Requirement from the core network CN via an AF request. This allows the SMF 546 to decide to relocate the PSA-UPF 520 based on the AF request in a network deployment where an estimated value of the delay in the user plane between the UE 40 and the candidate PSA-UPF 520 is known to the SMF 546.

[0343] The information about the AF change is information about the relocation of the AF 548. This information includes an AF ID, which is information for identifying the target AF 548 to which the change is made. The instruction for relocating the edge application server is an instruction to relocate an application.

[0344] When PCF545 is address-managed and distributed, a network function (e.g., AF548) that sends a policy regarding traffic identified by the address of UE40 needs to access PCF545, which holds information about the corresponding PDU session, via reference point N5.

[0345] The AF 548 may then possess at least one of the following pieces of information (or information about at least one of the following pieces of information) for the corresponding PDU session: User identity DNN UE IP or MAC address S-NSSAI Address of the selected PCF 545

[0346] For IP-based PDU sessions, the AF 548 receives information when an IP address is assigned or released to the PDU session.

[0347] For Ethernet-type PDU sessions that support MAC address-based AF request mapping, the AF 548 must receive information when the MAC address used by the UE 40 in the PDU session is detected. This MAC address detection is performed by the UPF 520 under the control of the SMF 546. Additionally, if TSC and time synchronization are supported, the AF 548 receives the MAC address of the Device-Side Time Sensitive Networking (TSN) Translator (DS-TT) port.

[0348] In addition, a binding support function (BSF) 552 may be used to associate the AF request with the PCF 545 .

[0349] The BSF 552 internally maintains information about the corresponding selected PCF 545 .

[0350] The BSF 552 may internally hold at least one of the following pieces of information (or information relating to at least one of the following pieces of information) for the corresponding PDU session: User identifier DNN UE IP address or MAC address S-NSSAI Address of the selected PCF 545

[0351] Furthermore, if available, the BSF 552 may internally maintain at least one of the following pieces of information (or information about at least one of the following pieces of information) for the corresponding PDU session: Identifier (ID) of the associated PCF instance; PCF set identifier; Level of association.

[0352] The BSF 552 may internally hold at least one of the following pieces of information (or information relating to at least one of the following pieces of information) for the corresponding UE 40: a user identifier; and an address of the selected PCF 545.

[0353] Furthermore, if available, the BSF 552 may internally maintain, for the corresponding UE 40, at least one of the following pieces of information (or information about at least one of the following pieces of information): - an identifier of the associated PCF instance; - a PCF set identifier; - a level of association.

[0354] The PCF 545 uses the Nbsf Management service to register, update, or delete the information it holds.

[0355] The PCF 545 updates this information whenever an IP address is assigned or released for the corresponding PDU session.

[0356] Alternatively, for Ethernet-type PDU sessions that support MAC address-based AF request mapping, PCF 545 updates the information each time it detects a MAC address used by UE 40 within a PDU session, or each time it detects that UE 40 will no longer use that MAC address.

[0357] The PCF 545 updates its information each time the AMF 541 selects a new PCF 545 for the corresponding UE 40.

[0358] AF requests targeted to an individual UE 40 by the UE 40's address are forwarded by the AF 548 or NEF 542 to the PCF 545 identified using the BSF 552.

[0359] Additionally, AF requests targeted at a group of UEs 40 or AF requests targeted at the following UEs 40 must go through the NEF 542: All UEs 40 that have access to a set of DNN and S-NSSAI UEs 40 classified by one or more GPSIs (Generic Public Subscription Identifiers) UEs 40 with an External Subscriber Category that is a set of external group IDs

[0360] The NEF 542 stores the information of the AF request in the UDR of the UDM 547. If the PCF 545 is registered for the service of creating, updating, or deleting the information of the AF request corresponding to the UDR Data Keys / Data Sub-Keys, it receives the corresponding notification.

[0361] If the AF 548 interacts with the PCF 545 via the NEF 542, the NEF 542 performs the mapping as described below.

[0362] The NEF 542 maps the AF-Service-Identifier to a set of DNN and S-NSSAI.

[0363] The NEF 542 maps the AF-Service-Identifier to a list of Data Network Access Identifiers (DNAIs) and routing profile IDs determined by the local configuration. The NEF 542 can provide this mapping only when the DNAIs used by the application are statically defined. If the DNAIs at which the application is instantiated change dynamically, the AF 548 provides the target DNAIs in the AF request, along with either the routing profile IDs or the N6 traffic routing information.

[0364] Here, DNAI is identification information for identifying user plane access to DN 530. Routing profile ID is identification information for referencing a routing policy previously agreed upon between AF 548 and the core network CN. N6 traffic routing information includes information required to forward traffic to DNAI.

[0365] The NEF 542 maps the GPSI contained in the Target UE Identifier to the SUPI according to the information received from the UDM 547 .

[0366] The NEF 542 maps the external group ID contained in the Target UE Identifier to an internal group ID according to information received from the UDM 547 .

[0367] The NEF 542 maps an external subscriber category and a UE 40, an external subscriber category and an external group ID to an internal group ID, or an internal group ID and a subscriber category.

[0368] The NEF 542 maps the geographical regions included in the Spatial Validity Condition to valid regions determined by local settings.

[0369] FIG. 13 is a diagram illustrating an example of a process for reflecting an AF request in the routing of a session.

[0370] The PCF 545 sends a Nudr_DM_Subscribe message to the UDR to register the AF-requested change service of the UDR (step S301). Here, the Data Set is application data. The Data Subset is AF traffic influence request information. The Data Key is at least one of the S-NSSAI, the DNN, and the internal group ID. The Data Key may be SUPI.

[0371] The AF 548 generates a new AF request (step S302), and then invokes the Nnef_TrafficInfluence_Create service on the NEF 542. Alternatively, the AF 548 invokes the Nnef_TrafficInfluence_Update service or the Nnef_TrafficInfluence_Delete service on the NEF 542 to modify or delete an existing AF request (step S303).

[0372] When the Nnef_TrafficInfluence_Create service or the Nnef_TrafficInfluence_Update service is started, the NEF 542 stores the AF request information in the UDR. When the Nnef_TrafficInfluence_Delete service is started, the NEF 542 deletes the AF request information from the UDR (step S304).

[0373] The NEF 542 responds to a request for the Nnef_TrafficInfluence_Create service, the Nnef_TrafficInfluence_Update service, or the Nnef_TrafficInfluence_Delete service from the AF 548 (step S305).

[0374] The PCF 545, which is registered in the AF request change service of the UDR, receives a notification of a change in data related to the information of the AF request from the UDR (step S306).

[0375] The PCF 545 determines whether any current PDU sessions are affected by the AF request, invokes the Npcf_SMPolicyControl_UpdateNotify service for each of those PDU sessions, and updates the SMF 546 with the new policy information corresponding to the PDU sessions (step S307).

[0376] When the SMF 546 receives the updated policy information regarding the PDU session from the PCF 545, it reconfigures the user plane of the PDU session in accordance with the updated policy information (step S308).

[0377] In addition, when the SMF 546 receives updated policy information regarding the PDU session from the PCF 545, it may perform the necessary processing to support discovery and re-discovery of an EAS (Edge Application Server) for a PDU session having a session breakout connection type.

[0378] Furthermore, in the case of N6-LAN Traffic Steering Control, the SMF 546 provides N6 traffic steering parameters to the UPF 520.

[0379] The SMF 546 determines whether it is necessary to send target DNAI information or common DNAI information to the AMF 541 to trigger SMF / I-SMF (Intermediate SMF) reselection, and then notifies the AMF 541 of the target DNAI information or common DNAI information for the current PDU session or the next PDU session via the Nsmf_PDUSession_SMContextStatusNotify service (step S309).

[0380] FIG. 14 is a diagram illustrating an example of a process for reflecting an AF request for an individual UE 40 in a policy.

[0381] The AF 548 sends an Nnef_TrafficInfluence_Create / Update / Delete request message to the NEF 542 (step S401), targeting the address of the individual UE 40. This request message corresponds to an AF request for reflecting traffic routing to a local network or Service Function Chaining (SFC).

[0382] Here, service function chaining is a chain of service functions that is constructed so that network functions can process packets in the appropriate order. A network function can provide one or more service functions.

[0383] A network operator defines a service function chaining policy for forwarding traffic associated with a given application, and can modify the policy to improve the user's Quality of Experience (QoE).

[0384] Service functions for 5G networks include, for example, firewall functionality, NAT (Network Address Translation), antivirus, parental control, DDoS (Distributed Denial of Service) protection, TCP proxy, load balancer, KPI monitoring, and EHE (Edge Hosting Environment).

[0385] A network operator can create, modify, or delete a single service function based on a service function chaining policy, and can also create, configure, or control a chain of service functions consisting of multiple service functions on a per-application and / or per-user basis based on the network operator's policy or a request from a third party.

[0386] If the address of the PCF 545 is not available, the NEF 542 requests the BSF 552 to use the Nbsf_Management_Discovery service to discover the address of the associated PCF 545 (step S402). If the address of the PCF 545 is available, step S402 is skipped.

[0387] The NEF 542 receives an Nbsf_Management_Discovery response message including the address of the PCF 545 from the BSF 552 as a response to the Nbsf_Management_Discovery request message (step S403).

[0388] The NEF 542 starts the Npcf_PolicyAuthorization service to reflect the AF request from the AF 548 in the policy, and then transmits an Npcf_PolicyAuthorization_Create / Update / Delete message to the PCF 545 (step S404).

[0389] The PCF 545 determines whether to permit the AF request. If the PCF 545 permits the request, it invokes the PCF initiated SM Policy Association Modification procedure. Then, the PCF 545 updates the SMF 546 with the corresponding new PCC rules (step S405). If the PCF 545 does not permit the request, it rejects the AF request.

[0390] When the SMF 546 receives the policy information from the PCF 545, it reconfigures the user plane of the PDU session according to the received policy information.

[0391] Through the above processing, the AF request from AF 548 can be reflected in the policy managed by PCF 545 and in the user plane processing of the PDU session managed by SMF 546.

[0392] Note that the service provided by the NEF 542, which reflects AF requests in policies managed by the PCF 545 and in user plane processing of PDU sessions managed by the SMF 546, is not limited to the Nnef_TrafficInfluence service. For example, the AF 548 can use the Nnef_AF_request_for_QoS service to request 5GS to provide a specific QoS for the traffic flow of a UE 40 or a group of UEs 40. This service can be used, for example, to support QoS monitoring registration and notification for monitoring packet delay.

[0393] The AF 548 can also use the Nnef_AfsessionWithQoS service to request QoS for a session for a particular UE 40. This service can be used to support registration and notification of QoS monitoring, e.g., for monitoring packet delay, congestion information, data rate, packet delay variation, etc. Furthermore, this service can be used to support registration and notification of BAT offsets, which will be described later, so that the AF 548 can adjust burst transmission times from the XR server 60 based on feedback from the RAN / AN 510.

[0394] The services provided by NEF542 illustrated here are just examples, and the services that reflect AF requests in policies managed by PCF545 and in user plane processing of PDU sessions managed by SMF546 may be other than these.

[0395] <4-3. TSC Support Information> Next, TSC (Time Sensitive Communication) support information will be described.

[0396] The TSCTSF 551 determines a TSC Assistance Container based on the traffic pattern provided by the AF 548, and provides the TSC Assistance Container to the PCF 545. Upon receiving the TSC Assistance Container from the TSCTSF 551, the PCF 545 transfers the TSC Assistance Container to the SMF 546 as part of a PCC rule. The transfer of the PCC rule including the TSC Assistance Container to the SMF 546 is performed in step S206 shown in FIG. 12A.

[0397] The SMF 546 associates a Policy and Charging Control (PCC) rule containing a TSC assistance container with a QoS flow. The SMF 546 uses the TSC assistance container to derive TSC assistance information for that QoS flow. The SMF 546 sends the derived TSC assistance information to the RAN / AN 510.

[0398] SMF546 defines the components of the TSC support information, namely, Periodicity, Periodicity Range, Burst Arrival Time (BAT), BAT Window, and Survival Time, in accordance with the 5G clock.

[0399] A period is the time interval between two data bursts, where a data burst is composed of multiple PDUs generated and transmitted by an application within a short period of time. For example, one or more PDU sets can be configured or assigned to the multiple PDUs that make up a data burst.

[0400] The period range indicates the lower and upper limits of the period as a range of acceptable periods within which the AF 548 can adjust the period.

[0401] The burst arrival time is defined as the latest possible time at which the first packet of a downlink data burst arrives at the input end of the RAN / AN 510 or the latest possible time at which the first packet of an uplink data burst arrives at the output end of the UE 40. For example, the downlink burst arrival time can be set to the burst arrival time set at the input end of the UPF 520 plus the CN PDB.

[0402] The BAT window indicates the earliest and latest allowable arrival times for the first packet of a data burst.

[0403] The time to live indicates the period during which an application can continue operation without receiving a data burst. The time to live is set either as the maximum number of messages equivalent to all packets in the data burst, or in units of time. If only one data burst is expected within a single period, the time to live corresponds to a period. The PCF 545 may also set the PDU set delay tolerance based on this time to live.

[0404] The TSCTSF 551 may also specify the flow direction (e.g., uplink or downlink) of the TSC flow in the TSC Support Container and TSC Support Information. A TSC flow is also referred to as a TSC QoS flow.

[0405] When the traffic pattern provided by the AF 548 is updated, the TSCTSF 551 updates the TSC support container. When the TSC support container is updated, the PCF 545 forwards the PCC rule including the updated TSC support container to the SMF 546. The SMF 546 updates the TSC support information based on the updated TSC support container. The updated TSC support information is sent to the RAN / AN 510.

[0406] If the RAN / AN 510 receives TSC assistance information including a BAT window or capability for BAT adaptation for a QoS flow, it can determine a BAT offset to align the arrival of a data burst with the next scheduled transmission opportunity.

[0407] When the RAN / AN 510 receives TSC assistance information including a Periodicity Range for a QoS flow, it can determine the period to be adjusted along with the BAT offset identified above to align the period of the data burst with the expected time interval between subsequent transmission opportunities.

[0408] For adaptive control of the BAT and period, the BAT offset and adjusted period are fed back to the SMF 546 as part of the QoS flow establishment or modification process.

[0409] <4-4. MPL, PRPL, and RPL in XR Architecture> Next, we will explain MPL (Motion to Photon Latency), RPL (Render to Photon Latency), and PRPL (Pose to Render to Photon Latency) in the XR architecture.

[0410] According to the architecture of FIG. 8, the total processing time in the XR display area rendering unit 76 without taking into account the time warp function can be estimated as follows:

[0411] First, the 3DOF / 6DOF tracking and XR sensor unit 71 performs the processing period PT Ｓｅｎｓｅ Detect the user's pose information.

[0412] The 5GS distribution unit 73 transmits the tracking and sensor information detected by the XR device 70 to the PDB using an uplink QoS flow via the RAN / AN 510. ＵＬ The tracking and sensor information is transmitted to the 5GS distribution unit 66 within the period of time. Here, the tracking and sensor information is information including, for example, pose information and / or inertial information.

[0413] The XR media generation unit 61, the XR display area pre-rendering unit 62, the 2D / 3D media encoding unit 63, and the XR rendering metadata processing unit 64 perform the processing time PT Ｓｅｒｖｅｒ The XR media content to be sent to the XR device 70 is generated.

[0414] The 5GS distribution unit 66 transmits the XR media content distributed by the XR media content distribution unit 65 to the PDB using a downlink QoS flow via the RAN / AN 510. ＤＬ The signal is transmitted to the 5GS distribution unit 73 within the period.

[0415] The 2D / 3D media decoding unit 74, the XR rendering metadata processing unit 75, and the XR display area rendering unit 76 perform the processing time PT Ｄｉｓｐｌａｙ The XR media is displayed on the display unit 77.

[0416] That is, it takes time T shown in the following formula (1) from when the 3DOF / 6DOF tracking and XR sensor unit 71 starts detecting the movement of the XR device 70 until the XR media is displayed on the display unit 77.

[0417] T = PT Sense +PDB UL +PT Server +PDB DL +PT Display ...(1)

[0418] According to 3GPP TR26.928 "Extended Reality (XR) in 5G," a motion-to-photon latency (MPL) of 20 ms or less is required as the quality-of-experience (QoE) for XR. For example, 5QI:87, which is provided as a TSC QoS flow for motion tracking data, has a PDB of 5 ms, and 5QI:88 has a PDB of 10 ms. 5QI:89, which is provided as a TSC QoS flow for video content for cloud, edge server, or split rendering, has a PDB of 15 ms, and 5QI:90 has a PDB of 20 ms. Even if these PDBs are substituted into the above formula (1), it can be seen that it is difficult to satisfy an MPL of 20 ms or less.

[0419] Therefore, the total processing time when taking into account the time warp function in the XR display area rendering unit 76 can be estimated as follows:

[0420] FIG. 15 is a diagram showing an example of a timing chart relating to each process in Generalized XR Split Rendering.

[0421] The tracking and sensor information #1 detected by the 3DOF / 6DOF tracking and XR sensor unit 71 is stored in the PDB ＵＬ It is transmitted to the 5GS distribution unit 66 within the period #1.

[0422] The XR server 60 determines the processing time PT Ｓｅｒｖｅｒ XR media content #1 is generated within the period #1. XR media content #1 is stored in the PDB ＤＬ It is transmitted to the 5GS distribution unit 73 within the period #1.

[0423] During the rendering process for the received XR media content #1, the XR display area rendering unit 76 performs time warp processing using the latest tracking and sensor information #2 detected by the 3DOF / 6DOF tracking and XR sensor unit 71, to generate XR media #1.

[0424] The display unit 77 displays the XR media #1 generated by the XR display area rendering unit 76 at frame timing #1. The frame period is 16.7 ms for 60 fps, for example.

[0425] Here, XR media content #1 displayed at frame timing #1 has a second display area based on tracking and sensor information #2, not a first display area based on tracking and sensor information #1. Therefore, the starting point of MPL is tracking and sensor information #2, not tracking and sensor information #1. This allows for a reduction in MPL.

[0426] However, XR media content #1 must be data that includes not only the first display area based on tracking and sensor information #1, but also the second display area based on tracking and sensor information #2. Otherwise, the displayed image cannot be corrected by coordinate transformation using time warp alone. In other words, the effect of time warp will not be effective for XR media content based on older tracking and sensor information.

[0427] Therefore, 3GPP TR26.928 "Extended Reality (XR) in 5G" requires a render-to-photon latency (RPL) of 50 ms or less as the QoE for XR. The RPL is based on requirements for interaction delay, which is the delay caused by interaction, and / or age of content, which is the validity period of content. The RPL also depends on the application. For example, the interaction delay is expected to be 50 ms, 100 ms, 200 ms, or more than 200 ms, depending on the application.

[0428] In the processing in the architecture shown in Fig. 8, PRPL (Pose to Render to Photon Latency) can be considered as the time from when tracking and sensor information is detected until the XR device 70 displays the XR media content generated by the XR server 60 based on the tracking and sensor information on the display unit 77 without applying time warp. For example, PRPL can be considered as the time from when the 3DOF / 6DOF tracking and XR sensor unit 71 of the XR device 70 detects tracking and sensor information until the XR device 70 displays the XR media content generated by the XR server 60 based on the tracking and sensor information on the display unit 77 without applying time warp. For example, PRPL is the time calculated by the above formula (1).

[0429] Furthermore, the RPL can be considered as the time from when the XR server 60 starts generating the XR media content (or when the XR server 60 acquires tracking and sensor information) until when the XR device 70 displays the XR media content received from the XR server 60 on the display unit 77 without applying time warp.

[0430] For example, in the case of viewport-independent distribution, the required value of RPL may be set as information on a delay request regarding the reflection of a user's actions in video content. Also, in the case of viewport-dependent distribution, the required value of PRPL may be set as information on a delay request regarding the reflection of a user's actions in video content.

[0431] In a game application, the 3DOF / 6DOF tracking and XR sensor unit 71 may be a game controller for inputting operations. In this case, PRPL may be Click to Photon Latency.

[0432] Similarly, tracking and sensor information #2 and tracking and sensor information #3 detected by the 3DOF / 6DOF tracking and XR sensor unit 71 are transmitted to the XR server 60, XR media content #2 and XR media content #3 are generated by the XR server 60, and XR media #2 and XR media #3 are displayed on the display unit 77 at frame timing #2 and frame timing #3, respectively.

[0433] <<5. Operation of the Communication System>> Based on the above, the operation of the communication system 1 will be described.

[0434] In the following description, XR media refers to XR video content. The XR video content is, for example, an XR video such as a VR video. The XR video content is not limited to an XR video. The XR video content may be an XR game such as a VR game. Alternatively, the XR video content may be video content generated by calculating or processing 3D data (e.g., 3D spatial data and / or 3D object data) based on user viewpoint data.

[0435] <5-1. Overview of XR Media Distribution Processing> There is a demand for a sense of realism in XR media. Therefore, information processing devices that handle XR media (e.g., server 10 / terminal device 40) are expected to handle video information with higher resolution.

[0436] However, high-resolution video information requires a large amount of data. Therefore, if the server 10 (in the example of FIG. 8 , the XR server 60) begins to handle XR media, there is a concern that the processing time required for generating the XR media (in the example of FIG. 8 , the processing time required by the XR media generation unit 61 and the XR display area pre-rendering unit 62) will increase. Furthermore, in order for the server 10 to transmit data related to XR media via a TSC QoS flow (e.g., 5QI:89 or 5QI:90) for video content for cloud, edge server, or split rendering, the data related to XR media (e.g., 2D / 3D media related to XR media content) needs to be compressed at a higher compression rate. There is also a concern that the processing time required for encoding (in the example of FIG. 8 , the processing time required by the 2D / 3D media encoding unit 63) will increase. It is also possible that a new 5QI with a larger maximum data burst size will be defined in the future. In this case, from the relationship between 5QI:89 and 5QI:90, it is expected that the PDB will increase for a larger maximum data burst amount.

[0437] On the other hand, in XR media, it is necessary to reflect the user's actions in the XR media. In order for the user to enjoy the XR media without feeling uncomfortable (for example, for the user to enjoy VR videos without VR sickness), it is desirable for the user's actions to be quickly reflected in the XR media. In this embodiment, the server 10 distributes data related to the XR media (for example, XR media content) via a wireless network. Therefore, in order to quickly reflect the user's actions in the XR media, stable low-latency wireless transmission must be realized. However, it is difficult to achieve stable low-latency wireless transmission in a dynamically changing wireless environment. In this case, the user cannot enjoy the XR media without feeling uncomfortable.

[0438] Therefore, the communication system 1 of this embodiment performs the following processing to provide users with high-quality communication services related to XR (for example, to provide XR video content that stably follows the user's movements).

[0439] First, the server 10 of this embodiment identifies delay request information related to reflecting a user's action on the XR media. For example, the server 10 identifies an appropriate PRPL (Pose to Render to Photon Latency) or RPL (Render to Photon Latency) request value according to the XR application as the delay request information. At this time, the server 10 may identify a request value selected from multiple PRPL or RPL request values ​​according to the XR application as the delay request information.

[0440] The server 10 then acquires tolerance information regarding the transmission delay of the QoS flow assigned to the session established for the XR application. At this time, the tolerance information regarding the transmission delay (hereinafter simply referred to as tolerance information) may include a packet delay budget (PDB) of the QoS flow assigned to the session established for the XR application. For example, the tolerance information may include at least one of a PDB of the uplink QoS flow assigned to the session established for the XR application (hereinafter referred to as a first PDB) and a PDB of the downlink QoS flow assigned to the session established for the XR application (hereinafter referred to as a second PDB).

[0441] The server 10 then makes a decision regarding the generation of data (e.g., 2D / 3D media related to XR media content) to be distributed to the terminal device 40 (in the example of FIG. 8 , the XR device 70) based on the delay request information and the tolerance information. For example, the server 10 makes a decision regarding the generation of data related to XR media based on the delay request information and the PDB (at least one of the first PDB and the second PDB). At this time, the decision regarding the generation of data related to XR media may be a decision regarding at least one of the resolution and codec of the XR media (e.g., 2D / 3D media related to XR media content).

[0442] The server 10 then generates data related to the XR media (e.g., XR media content) in accordance with the determined information (e.g., information on at least one of the resolution and the codec), and transmits the generated data to the terminal device 40.

[0443] This allows the server 10 to adaptively deliver higher resolution XR media (e.g., XR video) to the terminal device 40 in accordance with the dynamically changing wireless communication quality, within a range that satisfies the delay requirement (requirement for PRPL or RPL). As a result, the user can enjoy high-quality XR media without feeling uncomfortable.

[0444] 5-2. First Example The outline of the XR media distribution process has been described above. Next, a specific example of the above-mentioned XR media distribution process will be described.

[0445] The XR media distribution process is divided into a session establishment process and a setting process. The session establishment process is a process in which the terminal device 40 (in the example of FIG. 8, the XR device 70) requests the core network CN to establish a session in conjunction with the launch of an XR application. The setting process is a process in which the server 10 (in the example of FIG. 8, the XR device 70) performs settings for creating XR media. After the setting process is completed, the server 10 creates data related to the XR media (XR media content) in accordance with the settings made in the setting process and distributes it to the terminal device 40.

[0446] In the following description, it is assumed that the core network CN has one or more network functions (for example, PCF 545, SMF 546, AF 548, TSCTSF 551, and UPF 520) shown in FIG.

[0447] The XR media distribution process (session establishment process, setting process) will be described below. The XR media distribution process is executed by the control unit 13 (identification unit 131 to notification unit 139) of the server 10.

[0448] <Session Establishment Processing> First, the session establishment processing will be described with reference to a flowchart of FIG.

[0449] The terminal device 40 identifies an XR application to be used from among multiple XR applications (step S501). Furthermore, the terminal device 40 identifies a network slice corresponding to the identified XR application (step S502). Here, identifying a network slice includes selecting one S-NSSAI from one or more S-NSSAIs included in the Allowed NSSAI. Alternatively, identifying a network slice includes selecting one S-NSSAI that is permitted in the currently serving tracking area from partial network slices within the registration area.

[0450] The terminal device 40 requests the core network CN to establish a session for the identified network slice (step S503). The session establishment process is performed, for example, by step S108 in Figures 11 and 12A. Here, the PDU Session Establishment Request message includes the S-NSSAI and DNN set selected in step S502. As described above, the core network CN has one or more network functions (e.g., PCF 545, SMF 546, AF 548, TSCTSF 551, and UPF 520) shown in Figure 7.

[0451] Upon receiving the Nsmf_PDUSession_Create_SMContext Request message initiated by the PDU Session Establishment Request message from the terminal device 40, the SMF 546 acquires the PCC rule for the S-NSSAI selected in step S502. This PCC rule acquisition process is executed, for example, in step S206 of the PDU session establishment process shown in FIG. 12A. This S-NSSAI is a network slice for a multi-modal service, and the PCF 545 provides the SMF 546 with a PCC rule including QoS profiles of multiple QoS flows for one established PDU session.

[0452] The multiple QoS flows include at least an uplink (UL) QoS flow for transmitting sensor information detected by the sensor unit 46 of the terminal device 40 to the server 10, and a downlink (DL) QoS flow for transmitting XR media content generated by the server 10 to the terminal device 40. Here, the sensor unit 46 of the terminal device 40 corresponds to the 3DOF / 6DOF tracking and XR sensor unit 71 of the XR device 70 shown in Fig. 8. Furthermore, the sensor information corresponds to the tracking and sensor information shown in Fig. 8.

[0453] The AF 548 may request a multi-modal service for an application processed between the terminal device 40 serving as an XR device and the server 10 serving as an XR server from the core network CN. The AF 548 may provide a multi-modal service ID to the PCF 545 using a service provided by the NEF 542, for example, the Nnef_AfsessionWithQoS service, to explicitly notify that the traffic of the application is related to the multi-modal service.

[0454] The AF 548 may provide the PCF 545, either directly or via the NEF 542, with QoS monitoring requirements for data flows associated with the multimodal service.

[0455] In the case of multimodal services to one terminal device 40, closely related data flows that require application coordination to correctly deliver data of the multimodal application are expected to be transmitted in one PDU session.

[0456] Furthermore, in the case of a multimodal service for multiple terminal devices 40, the same DNN and S-NSSAI set should be selected, and therefore the same DNN / S-NSSAI is selected by the evaluation framework of the URSP rules. The AF 548 can assign the same multimodal service ID to the PDU sessions of all terminal devices 40 that make up the multimodal service. The PCF 545 takes the assigned multimodal service ID into account when processing each PDU session independently, for example, to assign a specific QoS profile.

[0457] The AF 548 may also provide round trip (RT) delay requirement information for interactive media services such as XR to the PCF 545. Based on the RT delay requirement information, the PCF 545 divides the RT delay into two packet delay budgets (PDBs) for each PCC rule for uplink (UL) traffic, uplink QoS flows for transmitting downlink (DL) traffic, and downlink QoS flows.

[0458] Two PDBs, namely, the PDB of the uplink QoS flow (hereinafter referred to as PDB ＵＬ ) and downlink QoS flow PDB (hereinafter referred to as PDB ＤＬ However, the values ​​of the two PDBs are set so that the sum of the two PDBs does not exceed the delay of the RT.

[0459] The RT delay that the server 10 requests from the PCF 545 via the AF 548 is set based on the requested value for Pose to Render to Photon Latency (PRPL) / Render to Photon Latency (RPL) according to the XR application.

[0460] The PCF 545 generates the above-mentioned QoS monitoring policy for the two associated QoS flows to track the status of the RT delay. When the QoS monitoring results are reported to the PCF 545, the PCF 545 sums the QoS monitoring report results for the uplink and downlink packet delays to generate the RT delay result. Based on this result, the PCF 545 checks whether the RT delay requirement is met.

[0461] The PCF 545 may optionally reconcile the PDBs of the two PCC rules using the SM Policy Association Modification Procedure.

[0462] A multimodal service request may be included as an option in a service such as Nnef_AFsessionWithQoS_Create provided by the NEF 542. The multimodal service request includes, for example, information about multiple data flows handled by a multimodal application.

[0463] Here, the information regarding the plurality of data flows may include information regarding the flow direction of each data flow, i.e., uplink or downlink, and may further include the number of data flows for each flow direction.

[0464] The information relating to multiple data flows may include information on the QoS ID, for example, 5QI, requested for each data flow.

[0465] The information regarding the multiple data flows may include RT delay requirements for specified uplink and downlink data flows.

[0466] The information regarding the multiple data flows may include a requirement for time synchronization between the multiple uplink data flows.

[0467] The information regarding the multiple data flows may include a request for time synchronization between the multiple downlink data flows. This allows a communication device (e.g., the server 10, the management device 20, the base station 30, or the terminal device 40) to request the setting of two time-synchronized data flows so that the server 10 can transmit two different videos for the left and right eyes to the terminal device 40 when the terminal device 40 is a glasses-type wearable device.

[0468] A communication device may assign TSC flows to multiple uplink or downlink data flows. In this case, the communication device may include, in the information related to the multiple data flows, an instruction to apply TSC assistance information consisting of the same parameters to these TSC flows in order to request time synchronization between the TSC flows. Alternatively, the communication device may set a group or set consisting of multiple TSC flows requiring time synchronization. In this case, the communication device may apply a single TSC assistance information to this group or set.

[0469] For example, when delivering XR media content in the downlink, metadata for rendering 2D / 3D media and XR media can be assigned to different TSC flows, and these different TSC flows can be configured as one group or set. Here, by assigning different priorities to different TSC flows, it becomes possible to control, for example, to transmit a TSC flow assigned with metadata for rendering in priority over a TSC flow assigned with 2D / 3D media in each data burst based on the same TSC support information.

[0470] The information related to multiple data flows may include a PDU set configuration request for a data flow whose QoS ID indicates a TSC flow. Furthermore, the PDU set configuration request may include information related to the number of PDU sets to be configured for one data burst for each data flow. The information related to the number of PDU sets may be, for example, the number of PDU sets requested for configuration, or information identifying the type of data to be assigned to PDUs in one data burst. When multiple PDU sets are requested for configuration for one data burst, the PDU set configuration request may include information on the relative priority of each PDU set. Here, one data burst refers to a data burst for each period defined by one TSC support information.

[0471] For example, in foveated rendering (described later), the resolution within a single frame image may change depending on the distance from the center of gaze. For this reason, for example, foveated rendering requires the transmission of data of different resolutions as a single frame image. In this case, if a communication device prioritizes the delivery of data closer to the center of gaze (e.g., data with a resolution higher than a predetermined threshold), a mechanism is required to distinguish data of different priorities within a single data burst to which a single frame image is assigned. Therefore, the communication device sets multiple PDU sets with different priorities within a PDU of a single data burst. The communication device may then assign data of different priorities to each PDU of the multiple PDU sets with different priorities according to the priority of the data. This enables the prioritized delivery of data with higher resolution within a single data burst.

[0472] When a communication device requests the setting of multiple PDU sets for multiple uplink or downlink data flows, the communication device may request a relative allowable delay time between the PDU sets as a request for time synchronization.

[0473] Furthermore, when a communication device requests the setting of a PDU set, the communication device may request measurement of the delay of the PDU set as a request related to QoS monitoring. Note that when a communication device requests the setting of multiple PDU sets, the communication device may request measurement of the delay for each PDU set. Furthermore, the communication device may specify two PDU sets and request measurement of the relative delay between the PDU sets.

[0474] One of the PDU set QoS parameters is the PDU set delay tolerance. The basis for the PDU set delay tolerance is the timing at which the first PDU of the PDU set is received. The reception timing of a periodically received PDU set is assumed to have jitter. In other words, when a communication device estimates the timing at which it will complete reception of all PDUs in a PDU set taking the PDU set delay tolerance into account, the timing at which it completes PDU reception in each period will vary depending on jitter. On the other hand, if the data sent using the PDU set payload is XR media video, the terminal device 40 must receive the data and start decoding and rendering processing by the periodic reception deadline regardless of jitter in order to display it at a periodic frame rate. Therefore, the PDU set configuration request information may include a PDU set delivery deadline (PSDD) configuration request as a PDU set QoS parameter instead of the PDU set delay tolerance.

[0475] When PCF 545 receives a request to set a PDU set delivery deadline, it includes an indication in the request information for setting the PDU set that the PDU set delivery deadline is to be set instead of the PDU set delay tolerance time as a PDU set QoS parameter.

[0476] Assume now that the base station 30 (RAN / AN 510 in the example of FIG. 7) has received PDU set QoS parameters including an instruction to set a PDU set delivery deadline instead of the PDU set delay tolerance. In this case, the base station 30 sets the PDU set delivery deadline to the sum of the burst arrival time in each period and the lifetime, based on the burst arrival time of the TSC support information, for example. This PDU set delivery deadline allows the base station 30 to determine the timing at which transmission of all PDUs in the PDU set must be completed, without being affected by jitter when receiving the PDU set.

[0477] In addition, when both the PDU set delay allowable time and the PDU set delivery deadline are set as PDU set QoS parameters, the base station 30 may prioritize the PDU set delivery deadline.

[0478] The information regarding the multiple data flows may include a Transaction Reference ID of the Ntsctsf_QoSandTSCAssistance_Create service to the TSCTSF 551. Here, the AF 548 may provide information regarding the traffic pattern of each data flow (e.g., flow direction, burst arrival time, period, time domain, time to live, BAT window, or burst arrival time adaptive control capability, period range) using the Ntsctsf_QoSandTSCAssistance_Create service. This allows the AF 548 to request the TSCTSF 551 to generate a TSC assistance container. The Transaction Reference ID is an ID obtained in response to the request.

[0479] The AF 548 may also include information about the traffic pattern of each data flow in the information about the multiple data flows. Then, on behalf of the AF 548, the PCF 545 may request the TSCTSF 551 to generate a TSC support container.

[0480] <Setting Process> Next, a description will be given of the setting process according to the first embodiment. Fig. 17 is a flowchart showing the setting process according to the first embodiment.

[0481] When a session is established in accordance with a request from the terminal device 40, the server 10 identifies delay request information for the XR application being used. For example, the server 10 identifies a PRPL (Pose to Render to Photon Latency) / RPL (Render to Photon Latency) request value as the delay request information (step S601). For example, assume that the delay request information is a PRPL request value. In this case, the PRPL request value is, for example, 50 ms or less, 100 ms or less, 200 ms or less, or some other value (e.g., 500 ms or less) depending on the XR application being used.

[0482] Here, the server 10 may set the frame rate of the XR media according to the XR application being used in accordance with the specified delay requirement information (e.g., the required PRPL value). For example, the server 10 may set 60 fps for a normal XR application, and 90 fps or 120 fps for an XR application that requires a higher MPL (Motion to Photon Latency) than a predetermined standard.

[0483] In the following description, the delay request information is assumed to be a PRPL request value. Note that the delay request information is not limited to a PRPL request value. The term "PRPL request value" that appears in the following description can be replaced with, for example, "delay request information" or "RPL request value." Furthermore, the term "PRPL" can be replaced with, for example, "RPL."

[0484] The server 10 acquires information about the QoS flow allocated to the session for XR media delivery of the XR application being used from the core network CN (e.g., NEF 542) via the AF 548 (step S602). Here, the AF 548 may request acquisition of information about the QoS flow allocated to the session for XR media delivery via an AF request.

[0485] The server 10 identifies allowable information regarding transmission delay (for example, PDB (Packet Delay Budget)) from the acquired information regarding the QoS flow.

[0486] For example, the server 10 may create a PDB (Profile Database) from the acquired information about the QoS flow (for example, information about the 5QI assigned to the uplink (UL)). ＵＬ (Step S603). When a PDU set is set for an uplink QoS flow, the server 10 identifies the PDB ＵＬ Alternatively, the server 10 may add the PDU set delay allowable time (or a time calculated based on the PDU set delay allowable time) to the PDB ＵＬ A time based on the survival time (or a time calculated based on the survival time) may be further added to the above.

[0487] The server 10 also creates a PDB from the acquired information about the QoS flow (for example, information about 5QI assigned to the downlink (DL)). ＤＬ (Step S604). When a PDU set is set for a downlink QoS flow, the server 10 identifies the PDB ＤＬ Alternatively, the server 10 may add the PDU set delay allowable time (or a time calculated based on the PDU set delay allowable time) to the PDB ＤＬ A time based on the survival time (or a time calculated based on the survival time) may be further added to the above.

[0488] The server 10 selects a resolution and a codec to be set as candidate settings. Here, the candidate codec may be a codec selected from a plurality of selection candidates including at least one of AVC / H.264, HEVC / H.265, and VVC / H.266, for example. Note that the plurality of selection candidate codecs may include codecs other than these. Furthermore, the server 10 may select, as the candidate resolution and codec, a resolution and a codec that are equal to or less than the maximum data burst amount specified based on the 5QI information assigned to the DL. Note that the server 10 may select only one of the resolution and the codec as the candidate setting.

[0489] The server 10 calculates the processing time PT for the resolution and / or codec that are the setting candidates. Ｓｅｒｖｅｒ (Step S605). The server 10 calculates the specified PDB (for example, PDB ＵＬ , and PDB ＤＬ At least one of the above) and the calculated PT Ｓｅｒｖｅｒ Based on this, the PRPL is calculated (step S606).

[0490] The server 10 determines whether the calculated PRPL is equal to or less than the required value for the XR application (step S607). If the calculated PRPL is equal to or less than the required value for the XR application (step S607: Yes), the server 10 sets the resolution and codec selected as the setting candidates as the resolution and codec to be used for generating the XR media content (step S608). Note that the server 10 may set only one of the resolution and codec. Once the setting is complete, the server 10 ends the setting process.

[0491] On the other hand, if the calculated PRPL exceeds the required value for the XR application (step S607: No), the server 10 lowers the resolution setting candidate by one level (step S609). For example, the server 10 lowers the resolution setting candidate from 4K to 2K. Then, the server 10 executes the process from step S605 onwards again.

[0492] Through the above process, the server 10 can set an appropriate resolution and / or codec for each of multiple XR applications with different PRPL / RPL requirements. As a result, the server 10 can generate XR media content that matches the QoS flow assigned to the session.

[0493] <Modification> The PCF 545 may send a confirmation of permission to change to an alternative QoS profile for a specified QoS flow to the AF 548 in accordance with the notification control of the QoS parameters notified from the SMF 546.

[0494] The AF 548 may allow a change to an alternate QoS profile if a specified QoS flow cannot meet the parameters of the current QoS profile.

[0495] When the AF 548 permits a change to an alternative QoS profile and obtains information on an alternative QoS profile that can currently be satisfied, the AF 548 stores the packet delay tolerance time included in the alternative QoS profile in the PDB (PDB ＵＬ and PDB ＤＬ The server 10 may then update at least one of the PDBs (PDB ＵＬ and PDB ＤＬ Furthermore, if the specified QoS flow is a downlink QoS flow and the maximum data burst size included in the alternative QoS profile is changed, the server 10 selects, in step S605, a resolution and / or a codec that is equal to or smaller than the updated maximum data burst size as a candidate resolution and / or codec to be set.

[0496] Furthermore, if the frame period of the XR media is not an integer multiple of the smallest unit of radio resources allocated by the base station 30 (e.g., 60 fps), an accumulated error in the fractional part causes an offset in the burst arrival time at the base station 30. Therefore, the SMF 546 may update the TSC support information for the target QoS flow by utilizing the BAT offset fed back from the base station 30. For example, if the BAT offset exceeds a threshold, the SMF 546 may change the burst arrival time in the TSC support information to correct the BAT offset. The SMF 546 provides the updated TSC support information to the base station 30 and instructs the base station 30 to update the TSC support information.

[0497] Here, the SMF 546 may obtain the upper limit value of jitter or packet delay variation required for a specific QoS flow from the AF 548. Then, the SMF 546 may set a threshold for an event that triggers the base station 30 to feedback the BAT offset to the base station 30 based on the upper limit value of jitter or packet delay variation. For example, the SMF 546 may set a value that is 75% of the upper limit value of jitter or packet delay variation as the threshold. The base station 30 may feed back the BAT offset to the SMF 546 when the BAT offset exceeds this threshold.

[0498] When the base station 30 receives the instruction to update the TSC support information, the base station 30 may update the TSC support information for the target QoS flow. If a PDU set is set for the target QoS flow, the base station 30 may further update the PDU set delivery deadline.

[0499] Here, reducing the resolution may involve selecting a format that requires a lower bit rate for delivery, i.e., in foveated rendering, allocating higher resolution data to a higher priority PDU set corresponds to allocating a higher bit rate format to a higher priority PDU set.

[0500] Furthermore, in step S609, instead of lowering the resolution by one level, the server 10 may divide the image related to the XR media content into multiple images with a reduced number of pixels and assign different priorities to the divided images. For example, the server 10 may divide a 4K-equivalent image into four 2K-equivalent images in terms of the number of pixels. FIG. 18 is a diagram showing an example of a method for dividing an image. In the example of FIG. 18, the server 10 divides a 4K-equivalent image into four 2K-equivalent images for each region. The server 10 can assign different priorities (transmission priorities) to the divided images and transmit them to the terminal device 40.

[0501] The server 10 (for example, the XR display area pre-rendering unit 62 of the XR server 60) may estimate the gaze center position based on sensor information acquired from the terminal device 40. Then, the server 10 identifies an image that includes the estimated gaze center position within the area from among the multiple divided images that make up the display area. The gaze center position can be detected using a technology called eye tracking. The server 10 then assigns the highest priority to the identified image. For other images, the server 10 assigns lower priorities as the images are further away from the gaze center position.

[0502] The terminal device 40 receives the PDB ＤＬ If the terminal device 40 receives only the highest priority 2K equivalent image during the period, the terminal device 40 can display the 2K equivalent image. ＤＬ If the terminal device 40 receives two images, that is, an image equivalent to 2K with the highest priority and an image equivalent to 2K with the second highest priority, during the period, the terminal device 40 can display half the area of ​​the image equivalent to 4K. ＤＬ If the terminal device 40 receives the 2K equivalent image with the highest priority, the 2K equivalent image with the second highest priority, and the 2K equivalent image with the third highest priority during the period, the terminal device 40 can display 3 / 4 of the area of ​​the 4K equivalent image. ＤＬ If four 2K-equivalent images are received within this period, the terminal device 40 can display an image equivalent to 4K.

[0503] The server 10 may use a service provided by the NEF 542, for example, the Nnef_AfsessionWithQoS service, to provide the core network CN with information related to PDU set configuration, including information on the number of PDU sets to be configured for multiple PDUs constituting each data burst and relative priorities among the PDU sets. Here, the server 10 may provide the number of image divisions or information for identifying the image data to be divided, as the information related to the number of PDU sets to be configured for multiple PDUs constituting each data burst. In other words, the server 10 may transmit multiple divided images with different priorities using multiple PDU sets with different priorities assigned to one data burst under PDU set-based QoS control.

[0504] The PCF 545 may provide the TSC support container and the associated support information (information related to PDU configuration) to the SMF 546. The SMF 546 may generate the TSC support information based on this information. Furthermore, the SMF 546 may generate a Protocol Description of the PDR included in the N4 rule provided to the PSA-UPF 520 based on the support information (information related to PDU configuration).

[0505] The PSA-UPF 520 may identify packets related to the divided multiple images with different priorities according to the Protocol Description of the PDR, and assign the identified packets related to each image to a PDU set with a different priority according to the priority of the image.

[0506] Furthermore, the PSA-UPF 520 may determine the PDU set information according to the Protocol Description of the PDR. The PSA-UPF 520 includes the PDU set information in a GTP-U header and transmits it to the base station 30 (RAN / AN 510).

[0507] Here, the SMF 546 sets an N4 rule in the PSA-UPF 520. The N4 rule is, for example, information for forwarding packets assigned to PDU sets with different priorities within one data burst according to the priorities. For example, the N4 rule is a gate control list for the Hold and Forward mechanism.

[0508] The Hold and Forward mechanism is a traffic priority control mechanism using up to eight queues with a protected window. The gate control list is a list that sets the duration of each time slot and whether data from each queue is passed or blocked by the gate for each time slot.

[0509] A specific queue (e.g., a PDU of a PDU set) can be given priority for transmission by setting a time slot for passing the specific queue (e.g., a PDU of a PDU set) as a protection window, where the duration of the protection window is set to, for example, the same duration as the time to live or a shorter duration.

[0510] The PCF 545 may set the PDU set delay tolerance based on the protection window duration. Furthermore, the PCF 545 may provide the protection window duration to the base station 30 when requesting the setting of the PDU set delivery deadline instead of the PDU set delay tolerance. In this way, the PCF 545 may instruct the base station 30 to set the PDU set delivery deadline based on the protection window duration.

[0511] The base station 30 allocates radio resources according to the priority of the PDU set and transmits the PDU set to the terminal device 40. That is, the base station 30 allocates radio resources preferentially to PDU sets with higher priority. Here, the base station 30 may determine the timing of the start of the PDU set allocated to each data burst based on the BAT (Burst Arrival Time) in the TSC support information.

[0512] Through the above processing, the terminal device 40 can display an image with a higher resolution near the line of sight. Here, an example of dividing a 4K-equivalent image into 2K-equivalent images has been shown, but this embodiment is not limited to this example. For example, a 2K-equivalent image may be divided into four Full HD (High Definition)-equivalent images, or a 4K-equivalent image may be divided into 16 Full HD-equivalent images. Alternatively, a 4K-equivalent image may be divided into 2K-equivalent images, and at least one of the four 2K-equivalent images may be divided into four Full HD-equivalent images.

[0513] Note that the method for dividing an image is not limited to the method of classifying by region as shown in FIG. 18 . FIG. 19 is a diagram showing another example of an image division method. The server 10 may divide an image related to XR media content into multiple images with substantially the same content but with reduced resolution. For example, as shown in FIG. 19 , the server 10 divides a 4K-equivalent image into multiple blocks, each consisting of four pixels. The server 10 then divides the image into four 2K-equivalent images: 2K-equivalent image 1 consisting of the upper left pixel 1 of each block; 2K-equivalent image 2 consisting of the upper right pixel 2 of each block; 2K-equivalent image 3 consisting of the lower left pixel 3 of each block; and 2K-equivalent image 4 consisting of the lower right pixel 4 of each block. In other words, the server 10 can divide an image related to XR media content into four images with the number of pixels thinned out in half vertically and horizontally.

[0514] Furthermore, the server 10 (e.g., the XR display area pre-rendering unit 62 of the XR server 60) may use both the method shown in Fig. 18 and the method shown in Fig. 19 for foveated rendering. For example, the server 10 may divide an image related to XR media content into four 2K-equivalent images for each area according to the method shown in Fig. 18, and thin out the 2K-equivalent images that are far from the position of the center of gaze into four full HD-equivalent images according to the method shown in Fig. 19. The server 10 may then assign a lower priority to these four full HD-equivalent images than to 2K-equivalent images whose area includes the position of the estimated center of gaze.

[0515] As a result, the terminal device 40 ＤＬ During this period, the terminal device 40 can receive, with priority, a high-resolution image that includes the position of the center of the gaze within that region. Furthermore, if one of the four low-priority full HD-equivalent images can be received, the terminal device 40 can display a full HD-equivalent image with a reduced number of pixels in an area away from the position of the center of the gaze. In this case, when a full HD-equivalent image 1 consisting of pixel 1 in the upper left corner is received, the terminal device 40 may copy and interpolate information from pixel 1 to pixel 2 in the upper right corner, pixel 3 in the lower left corner, and pixel 4 in the lower right corner, and then display the interpolated image.

[0516] Note that the above-described image division method is merely an example. The number of divisions into the image is not limited to four. For example, the number of divisions may be other numbers, such as two, nine, or sixteen. Furthermore, the divided areas do not need to be equal; the server 10 may divide the image into areas of different sizes. Also, the 2K and full HD shown in the above example are examples of resolutions. Other resolutions, such as 4K and 8K, may be applied.

[0517] Furthermore, the server 10 may unicast different video data to multiple terminal devices 40 that can use the 5GC shared MBS traffic delivery method. In this case, in step S609, instead of lowering the resolution by one level, the server 10 may transmit first data (multicast transmission data), which is a data portion of the same video among the video data being distributed to each terminal device 40, to the multiple terminal devices 40 by multicast via shared transport. Then, the server 10 may transmit second data (unicast transmission data), which is the other data portion of each video data, to the multiple terminal devices 40 by unicast via individual PDU sessions. Note that the server 10 may perform this control only when the base station 30 is capable of PTM (Point-to-Multipoint) transmission.

[0518] Here, the plurality of terminal devices 40 may be terminal devices 40 included in a terminal device group that is set in advance or dynamically. Information related to this terminal device group may be provided from the AF 548 to the core network CN.

[0519] The server 10 may set one resolution for one piece of multicast transmission data for a plurality of terminal devices 40, and may set the same or different resolutions for a plurality of unicast transmission data.

[0520] The server 10 may set one codec for one piece of multicast transmission data for a plurality of terminal devices 40, and may set the same or different codecs for a plurality of unicast transmission data.

[0521] Here, the core network CN may allocate different QoS flows to data for multicast transmission and data for unicast transmission.

[0522] For example, the core network CN may assign an MBS (Multicast / Broadcast Service) QoS flow to multicast transmission data. In this case, for example, the same data is transmitted as multicast transmission data to the terminal devices 40 of multiple users playing a multi-play game. On the other hand, different data is transmitted as unicast transmission data to the terminal devices 40 of multiple users playing a multi-play game.

[0523] The core network CN may obtain one copy of the data for the multicast transmission and may then transmit the one copy of the data for the multicast transmission to the base station 30 via shared transport using the 5GC Shared MBS traffic delivery method.

[0524] The core network CN may transmit individual unicast transmission data for multiple users' terminal devices 40 to the base station 30 via individual PDU sessions established with the multiple users' terminal devices 40.

[0525] Here, the core network CN may synchronize the data flows allocated to individual PDU sessions established between multiple users' terminal devices 40 with the data flows (MBS QoS flows) allocated to shared transport for 5GC shared MBS traffic transmission according to a request from the AF 548. For example, the core network CN may set periodic data bursts with the same settings as the data flows allocated to shared transport to the data flows allocated to individual PDU sessions.

[0526] More specifically, the core network CN may allocate TSC flows to data flows allocated to shared transport and data flows allocated to individual PDU sessions in accordance with a request from AF548, and apply TSC support information consisting of the same parameters to these TSC flows.

[0527] The core network CN may also allocate PDU sets of different priorities to data for multicast transmission and data for unicast transmission, which are periodic data bursts, respectively, For example, the core network CN may allocate a higher priority PDU set to data for multicast transmission than to data for unicast transmission.

[0528] Furthermore, the core network CN may assign PDU sets with different priorities to individual unicast transmission data for terminal devices 40 of multiple users.

[0529] The base station 30 may allocate radio resources according to the priority of the PDU set. For example, the base station 30 may allocate radio resources preferentially to multicast transmission data to which a high-priority PDU set is allocated. Alternatively, the base station 30 may allocate radio resources preferentially to individual unicast transmission data for a terminal device 40 to which a high-priority PDU set is allocated.

[0530] The transmission method described here (a method of separating user plane data into data for multicast transmission and data for unicast transmission and transmitting the separated data) can also be applied to XR applications other than multiplayer games.

[0531] Here, the method for extracting information about the same video from different videos may be, for example, a method using an Artificial Intelligence / Machine Learning (ML) model, which will be described later. The server 10 may input pixel information about the video to the input layer of the AI / ML model, and obtain data for multicast transmission and data for unicast transmission from the output layer.

[0532] Furthermore, when determining radio resource allocation according to the priority of a PDU set, the base station 30 may further consider PDU set aggregation processing information of the PDU set QoS parameters. For example, assume that the PDU set aggregation processing information indicates that X% (e.g., 75%) of all PDUs in a PDU set are required. In this case, for a terminal device 40 whose communication quality with the base station 30 is equal to or higher than a threshold, the base station 30 allocates radio resources to only X% of the PDUs in the PDU set and discards the remaining PDUs. Here, the communication quality may be, for example, SS (Synchronization Signal)-RSRQ (Reference Signal Received Quality) or CSI (Channel State Information)-RSRQ.

[0533] In addition, when using forward error correction (FEC), the server 10 may provide the core network CN via AF 548 with the percentage of required PDUs among all PDUs in the PDU set for PDU set aggregation processing information.

[0534] Here, the proportion of the required PDUs among all PDUs in the PDU set may vary depending on the forward error correction method used. The communication device may select a forward error correction method depending on the contribution of the processing time required for forward error correction to the required value of PRPL / RPL.

[0535] The PCF 545 may determine the PDU set QoS parameters according to information provided by the AF 548 and / or local configurations. For example, the PCF 545 may determine PDU set aggregation processing information indicating that X% (e.g., 75%) of all PDUs in the PDU set are required.

[0536] As part of the N4 rule, the SMF 546 may set the required proportion of PDUs among all PDUs of the PDU set indicated by the PDU set aggregation processing information to the PSA-UPF 520.

[0537] The PSA-UPF 520 may assign a priority higher than a predetermined threshold to X% of all PDUs in the PDU set, and assign a priority lower than the predetermined threshold to the remaining PDUs.

[0538] The base station 30 may determine radio resource allocation according to the priorities of the PDUs included in the PDU set. That is, the base station allocates radio resources preferentially to PDUs assigned higher priorities. Furthermore, the base station may determine to discard PDUs assigned lower priorities in the case of congestion.

[0539] By using the above-described PDU set integration processing information, it is expected that forward error correction can be utilized and transmission efficiency can be improved.

[0540] <5-3. Second Example> Next, the XR media distribution process of the second example will be described. As described above, the XR media distribution process is divided into a session establishment process and a setting process. The session establishment process is the same as the session establishment process according to the first example, so a description thereof will be omitted. Below, the setting process according to the second example will be described.

[0541] 20 is a flowchart showing the setting process according to the second embodiment. The processes from step S601 to step S607 and the process of step S608 are the same as the setting process according to the first embodiment shown in FIG. 17, and therefore a description thereof will be omitted.

[0542] If it is determined that the Pose to Render to Photon Latency (PRPL) calculated in step S606 exceeds the required value for the XR application (step S607: No), the server 10 identifies the maximum data burst volume (MDBV) from the information about the QoS flow acquired in step S602. For example, the server 10 determines the MDBV from the information about 5QI assigned to the downlink (UL). ＤＬ (Step S701). As described above, the description of "PRPL required value" can be replaced with "delay requirement information" or "RPL required value."

[0543] The server 10 identifies a codec with a small processing delay (i.e., a codec with a low compression rate) as a candidate codec (step S702). For example, the server 10 identifies the codec with the smallest processing delay (i.e., the codec with the lowest compression rate) from among multiple codecs that are candidates for selection. Then, the server 10 calculates the data size after compression based on the information of the identified codec (step S703).

[0544] The server 10 determines whether the calculated data size is equal to or smaller than the MDBV. ＤＬ It is determined whether the calculated data size is equal to or smaller than the value of MDBV (step S704). ＤＬ If the value is equal to or less than the value (step S704: Yes), the server 10 executes the process of step S608 and ends the setting process.

[0545] On the other hand, if the calculated data size is MDBV ＤＬIf the value of (step S704: No) is exceeded, the server 10 identifies a codec with a larger processing delay (i.e., a codec with a higher compression rate) than the codec identified in step S702 (or the codec identified in the previous step S704) (step S705). At this time, the server 10 may lower the resolution setting candidate by one level (step S609). Then, the server 10 executes the process from step S605 onwards again.

[0546] Through the above process, the server 10 can adaptively set the resolution and / or codec according to the maximum data burst amount of the assigned QoS flow.

[0547] In addition, if multiple PDU sets are set for one data burst, the server 10 may perform the above processing (e.g., processing from step S702 to step S609) on video data transmitted using the payload of at least one PDU set.

[0548] When performing the above process (e.g., the process from step S702 to step S609), the server 10 may select at least one PDU set. At this time, the server 10 may select, for example, one or more PDU sets to which a priority lower than a predetermined priority is assigned from among multiple PDU sets. Also, in step S703, the server 10 may calculate the sum of the sizes of data transmitted using the payloads of multiple PDU sets as the compressed data size.

[0549] When the server 10 performs the processes from steps S702 to S609 for a PDU set with a low priority, and then performs the processes from steps S702 to S609, the server 10 may select the PDU set with the next lowest priority in step S705.

[0550] In other words, when the server 10 divides frame images of a single video data and transmits them using the payloads of multiple PDU sets, it may set the resolution and / or codec for each divided frame image according to the maximum data burst amount of the assigned QoS flow. For example, the server 10 may assign a higher resolution to a frame image whose area includes the gaze center position, and assign lower resolutions to divided frame images according to the distance from the gaze center position. Furthermore, the server 10 may assign a higher priority to a frame image whose area includes the gaze center position. Then, the server 10 may assign a lower priority to divided frame images according to the distance from the gaze center position. This enables wireless transmission using the payloads of multiple PDU sets that is suitable for foveated rendering.

[0551] <5-4. Third Example> Next, the XR media distribution process of the third example will be described. As described above, the XR media distribution process is divided into a session establishment process and a setting process. The session establishment process is the same as the session establishment process according to the first example, so a description thereof will be omitted. Below, the setting process according to the third example will be described.

[0552] FIG. 21 is a diagram showing the range of data transmitted to the terminal device 40. As described above, the terminal device 40 using the time warp function identifies the latest display area (second display area) corrected based on the latest inertial information from the current display area (first display area). The terminal device 40 then performs coordinate conversion from the XR media adapted to the first display area to XR media adapted to the second display area. In other words, when the time warp function is used, the larger the range of movement of the display area, the larger the amount of data that the server 10 must transmit to the terminal device 40. Furthermore, the larger the PRPL / RPL, the larger the range of movement of the display area. Therefore, the server 10 needs to take the range of movement of the display area into consideration when setting the resolution and / or codec.

[0553] 22 is a flowchart showing an example of the setting process according to the third embodiment. The processes from step S601 to step S605 are the same as the setting process according to the first embodiment shown in FIG. 17, and therefore a description thereof will be omitted.

[0554] The server 10 reads the PDB (for example, PDB ＵＬ and PDB ＤＬ The image area is identified taking into consideration the amount of movement of the display area due to at least one of the above (step S801). The server 10 calculates the PRPL for the transmission data of the identified image area (step S802). For example, the server 10 calculates the PRPL based on the transmission data size of the identified image area. The term "PRPL" used in this embodiment can be replaced with "RPL".

[0555] Steps S607 and after are the same as those in FIG. 17, and therefore description thereof will be omitted.

[0556] Through the above process, the server 10 can access the PDB (for example, ＵＬ and PDB ＤＬ The PRPL value can be calculated taking into account the movement of the display area during the period (at least one of the above). As a result, the server 10 can set an appropriate resolution and / or codec based on a more accurate PRPL value.

[0557] Fig. 23 is a flowchart showing another example of the setting process according to the third embodiment. The processes from step S601 to step S801 are the same as those in the setting process shown in Fig. 22, and therefore a description thereof will be omitted.

[0558] The server 10 calculates the transmission data size of the image area identified in step S801 (step S901). The server 10 identifies the MDBV (Maximum Data Burst Volume) from the information about the QoS flow acquired in step S602. For example, the server 10 calculates the MDBV from the information about 5QI assigned to the downlink (UL). ＤＬ(Step S902). As described above, the description "PRPL required value" can be replaced with "delay requirement information" or "RPL required value."

[0559] The server 10 determines whether the calculated transmission data size of the image area is equal to or smaller than the MDBV. ＤＬ Then, it is determined whether the value of MDBV is equal to or less than the value of MDBV (step S903). ＤＬ If the PRPL is equal to or less than the value (step S903: Yes), the server 10 calculates the PRPL for the transmission data of the specified image area (step S802). The server 10 then executes the processes from step S607 onwards. The processes from step S607 to step S609 are the same as the setting process according to the first embodiment shown in Fig. 17, and therefore will not be described here.

[0560] On the other hand, if the calculated transmission data size of the image area is MDBV ＤＬ If the value of (step S903: No), the server 10 identifies a codec with a large processing delay (i.e., a codec with a high compression rate) (step S904). For example, the server 10 may identify a codec with a larger processing delay (i.e., a codec with a high compression rate) than the codec selected in the previous step S904 from among multiple codecs that are candidates for selection. For example, if HEVC / H.265 was selected in the previous step S904, the server 10 may select VVC / H.266 as the codec with a high compression rate. Then, the server 10 performs the processes from step S605 onwards again.

[0561] Through the above process, the server 10 can further set an appropriate resolution and / or codec depending on the maximum downlink data burst size.

[0562] FIG. 24 is a flowchart showing an example of a process for specifying an image area in consideration of the amount of movement of the display area.

[0563] The server 10 acquires sensor information (step S1001). Here, the sensor information corresponds to, for example, the tracking and sensor information shown in Fig. 8. Then, the server 10 identifies the magnitude of change in the amount of movement of the image area or the movement vector based on the history of the sensor information (step S1002).

[0564] The server 10 stores the magnitude or movement vector of the change in the XR media content and the PDB ( ＵＬ and PDB ＤＬ The server 10 identifies the image area based on the amount of movement of the display area due to the above (at least one of the above) (step S1003). When the identification is complete, the server 10 ends the identification process.

[0565] In the process of step S1002, the server 10 may acquire a trained AI (Artificial Intelligence) / ML (Machine Learning) model generated based on the history of sensor information. The server 10 may generate the trained AI / ML model based on the history of sensor information. Then, in step S1002, the server 10 may input the sensor information acquired in step S1001 into the trained AI / ML model to identify the magnitude of change in the amount of movement of the image region or the movement vector.

[0566] Here, the AI / ML model may be a neural network model based on machine learning or a deep neural network based on deep learning.

[0567] A neural network is composed of layers called an input layer, a hidden layer (or intermediate layer), and an output layer. Each layer contains at least one node. Each node is connected via an edge. Each layer has a function called an activation function, and each edge is weighted.

[0568] Machine learning is an artificial intelligence technique that allows a computer to perform recognition, judgment, or inference in the same way as a human. Machine learning processes consist of two processes: a learning process and a judgment process for recognition, judgment, or inference.

[0569] In the learning process, a device (not shown) that performs the learning uses the learning data to train the neural network model. During the learning process, the weight coefficients of each edge are optimized. The model extracted as a result of the learning process is the trained model.

[0570] In the determination process, a device (not shown) that performs the determination inputs data (e.g., sensor information) related to unknown data (e.g., the magnitude of change in the amount of movement of an image region or a movement vector) to a trained model. The trained model outputs a result of recognition, judgment, or estimation of the unknown data as a result of computation.

[0571] A deep neural network model contains multiple hidden layers. In machine learning, the number of hidden layers in a neural network model is limited by the limits of computer computing power. On the other hand, in deep learning, DNN (Deep Neural Network) models with a greater number of hidden layers are used due to improvements in computer computing power. Using a trained DNN model that has been trained using a huge amount of data improves the accuracy of recognition, judgment, or estimation.

[0572] Common algorithms used in deep learning include, for example: Convolutional Neural Network (CNN) Recurrent Neural Network (RNN) Fully connected neural network Long Short-Term Memory (LSTM) Autoencoder

[0573] In a CNN, the hidden layer is composed of layers called convolution layers and pooling layers. In the convolution layers, filtering is performed using convolution operations, and data called feature maps, for example, are extracted. In the pooling layers, the information in the feature maps output from the convolution layers is compressed and down-sampling is performed.

[0574] The RNN has a network structure in which values ​​of hidden layers are recursively input to hidden layers, and is used to process, for example, short-term time-series data.

[0575] In a fully connected neural network, all of the intermediate layers are fully connected layers (all nodes between layers are connected to each other). Fully connected neural networks have been applied mainly in the field of speech recognition.

[0576] In LSTM, parameters called memory cells that hold the state of the hidden layer are introduced into the output of the hidden layer of the RNN. This allows LSTM to retain the influence of outputs from the distant past. In other words, LSTM processes time-series data over a longer period than RNN.

[0577] Autoencoders extract low-dimensional features that can reproduce input data through unsupervised learning. Autoencoders are useful for noise removal and dimensionality reduction.

[0578] As described above, the server 10 uses the AI / ML model generated based on the history of sensor information to identify changes in the amount of movement of an image area, thereby enabling the server 10 to accurately estimate changes in the amount of movement of a dynamic image area.

[0579] The terminal device 40 may include information related to eye tracking in the sensor information. The server 10 may estimate a change in gaze using an AI / ML model generated based on the history of the sensor information.

[0580] In the above example, the server 10 performs the calculation process of the trained AI / ML model for estimating the change in the amount of movement of the image region. However, this embodiment is not limited to this.

[0581] For example, the server 10 may provide the trained AI / ML model to the terminal device 40. Then, the terminal device 40 may perform arithmetic processing of the trained AI / ML model to estimate a change in the amount of movement of an image region.

[0582] The terminal device 40 may transmit the results of the calculation processing of this trained AI / ML model (for example, the magnitude of change in the amount of movement of the image area, or information on the movement vector) to the server 10 as part of the sensor information.

[0583] In addition, the server 10 may provide a portion of the trained AI / ML model to the terminal device 40, and the calculation processing of the trained AI / ML model may be distributed between the terminal device 40 and the server 10.

[0584] The server 10 determines the division point of the learned AI / ML model by taking into consideration at least one of the communication quality between the terminal device 40 and the base station 30, the type of QoS flow that is the target of the uplink allocated for transmitting the results of the calculation processing of the learned AI / ML model, e.g., 5QI, the QoS monitoring results for the target QoS flow notified from the core network CN, or the quality of the QoS flow generated from the QoS monitoring results, e.g., the delay of the UL packets.

[0585] The terminal device 40 transmits the results of the arithmetic processing of the intermediate layer of the divided, trained AI / ML model to the server 10 as part of the sensor information. Note that the server 10 may first provide the trained AI / ML model to the terminal device 40 and notify the terminal device 40 of only the division points. The terminal device 40 can process only the layers preceding the notified division points and transmit the results of the arithmetic processing of the intermediate layer to the server 10. For example, when the division points are dynamically changed, the burden of transmitting the divided, trained AI / ML model to the terminal device 40 each time can be reduced.

[0586] <5-5. Fourth Example> Next, the XR media distribution process of the fourth example will be described. As described above, the XR media distribution process is divided into a session establishment process and a setting process. The session establishment process is the same as the session establishment process according to the first example, so a description thereof will be omitted. Below, the setting process according to the fourth example will be described.

[0587] In each of the above processes (e.g., the processes of FIGS. 17, 20, 22, and 23), the server 10 sets a resolution and / or codec appropriate for the XR application when transmitting XR media content to the XR device. At this time, the server 10 specifies delay requirement information (PRPL (Pose to Render to Photon Latency) / RPL (Render to Photon Latency) required value) according to the XR application. However, in reality, the information on the XR media content changes from moment to moment over the period during which the XR media content is transmitted. Depending on the magnitude of the change, the server 10 may need to change the PRPL / RPL required value. Therefore, in the fourth embodiment, the server 10 performs the setting according to the magnitude of the change in the video.

[0588] FIG. 25 is a flowchart showing an example of the setting process according to the fourth embodiment. The setting process according to the fourth embodiment is executed multiple times during the transmission of XR media content for one XR media. For example, the setting process according to the fourth embodiment is executed at regular time intervals during the transmission of XR media content for one XR media. The setting process according to the fourth embodiment will be described below with reference to the flowchart of FIG. 25.

[0589] The server 10 identifies the magnitude or speed of change in the video related to the XR media content (step S1101). Here, the magnitude or speed of change in the video refers to the magnitude of change or movement of an object included in the video. Alternatively, the magnitude or speed of change in the video refers to the magnitude of change or movement of 2D / 3D content multiplexed onto the video. Here, the server 10 may acquire information on the magnitude of change or movement of an object included in the video (hereinafter referred to as object change / movement information) using an AI / ML model. For example, the server 10 may input pixel information of the video into the input layer of the AI / ML model and acquire information obtained from the output layer as object change / movement information. Furthermore, the server 10 may detect the magnitude of change or movement of 2D / 3D content multiplexed onto the video based on sensor information acquired from the terminal device 40.

[0590] The server 10 sets a required PRPL value according to the magnitude / speed of the change in the video (step S1102). As described above, the term "required PRPL value" can be replaced with "request information" or "required PRPL value." When the magnitude / speed of the change in the video exceeds a first threshold, the server 10 sets a required PRPL value smaller than a predetermined threshold as the required value for the setting process. On the other hand, when the magnitude / speed of the change in the video is equal to or smaller than a second threshold, the server 10 sets a required PRPL value larger than the predetermined threshold as the required value for the setting process.

[0591] The server 10 calculates the processing time PT for the resolution and / or codec that are the setting candidates. Ｓｅｒｖｅｒ (Step S605). The server 10 calculates the specified PDB (for example, PDB ＵＬ , and PDB ＤＬ At least one of the above) and the calculated PT Ｓｅｒｖｅｒ Based on this, the PRPL is calculated (step S606).

[0592] The server 10 determines whether the PRPL calculated in step S606 is equal to or less than the required PRPL value set in step S1102 (step S1103). If the calculated PRPL is equal to or less than the required value set in step S1102 (step S1103: Yes), the server 10 sets the resolution and codec selected as the setting candidates as the resolution and codec to be used for generating the XR media content (step S608). Note that the server 10 may set only one of the resolution and codec. Once the setting is complete, the server 10 terminates the setting process.

[0593] On the other hand, if the calculated PRPL exceeds the required value set in step S1102 (step S1103: No), the server 10 lowers the resolution setting candidate by one level (step S609).Then, the server 10 executes the process from step S605 onwards again.

[0594] Through the above process, the server 10 can set appropriate PRPL / RPL requirement values ​​depending on the magnitude / speed of changes in the video, or the magnitude of changes or movements of 2D / 3D content multiplexed onto the video, thereby achieving the motion to photon latency (MPL) required to satisfy the user's quality of experience (QoE).

[0595] In step S1102, the server 10 may set the frame rate of the XR media in accordance with the setting of the PRPL required value. For example, if the magnitude / speed of the change in the video is equal to or less than the second threshold, the frame rate may be set to 60 fps, and if the magnitude / speed of the change in the video exceeds the first threshold, the frame rate may be set to 90 fps or 120 fps. In other words, the server 10 may dynamically change the frame rate depending on the magnitude / speed of the change in the video.

[0596] Furthermore, assume that the XR media content related to the XR media is composed of video data in GOP format. A GOP (Group of Picture) is a group consisting of multiple consecutive frames (I frames, P frames, and / or B frames). In this case, in step S609, the server 10 may change the frequency of I frames depending on the magnitude / speed of changes in the video, instead of lowering the resolution by one level.

[0597] I frames are also called key frames. A complete video is reproduced using only the data of this I frame. P frames contain prediction data for how the next frame will change from the previous frame. In addition to this P frame, information from the immediately preceding frame is referenced to reproduce a video. B frames contain data predicted from the frames before and after. In addition to this B frame, information from the frames before and after is referenced to reproduce a video. In this way, by using video data in GOP format, the amount of video data can be reduced, that is, compressed. One GOP contains one I frame as a key frame.

[0598] When the magnitude / speed of change in moving images is smaller than a predetermined reference value, the server 10 (for example, the 2D / 3D media encoding unit 63 of the XR server 60) reduces the transmission frequency of I frames below a threshold and increases the transmission frequency of P frames and / or B frames above a threshold. On the other hand, when the magnitude / speed of change in moving images is larger than the predetermined reference value, the server 10 increases the transmission frequency of I frames above the threshold and decreases the transmission frequency of P frames and / or B frames below the threshold.

[0599] A communication device (e.g., server 10) assigns a higher priority to I-frame data than to P-frame and B-frame data, and allocates data of each frame of a GOP to a PDU of a PDU set having a different priority according to the priority. The base station 30 allocates radio resources according to the priority of the PDU set and transmits the PDUs to the terminal device 40. In other words, the base station 30 allocates radio resources preferentially to PDUs of a PDU set with a higher priority.

[0600] By the above process, the server 10 can send data with higher importance in priority according to the magnitude / speed of changes in the video. Also, by the above process, the server 10 can reduce the amount of data to be transmitted.

[0601] 5-6. Fifth Example Next, a fifth example will be described. In the fifth example, control of the frequency of acquiring sensor information (that is, the frequency of transmitting sensor information by the terminal device 40) will be described.

[0602] In the XR media distribution process, the server 10 acquires sensor information from the terminal device 40. The server 10 may control the frequency with which the sensor information is acquired (i.e., the frequency with which the sensor information is transmitted by the terminal device 40). The process of controlling the frequency with which the sensor information is transmitted will be described below.

[0603] 26 is a flowchart illustrating an example of a process for controlling the frequency of transmission of sensor information. The process for controlling the frequency of transmission of sensor information is executed in the XR media distribution process.

[0604] As described above, in step S1102 shown in Fig. 25, the server 10 sets a required value for Pose to Render to Photon Latency (PRPL) according to the magnitude / speed of change in the video. The server 10 acquires the required value for PRPL set in step S1102 (step S1201 in Fig. 26). As described above, the term "requested value for PRPL" can be replaced with "delay request information" or "requested value for PRPL."

[0605] The server 10 determines whether the requested PRPL value acquired in step S1201 is equal to or less than the first threshold value (step S1202). If the requested PRPL value is equal to or less than the first threshold value (step S1202: Yes), the server 10 transmits a request to the terminal device 40 to increase the frequency of transmission of sensor information (step S1203). The server 10 may instruct the terminal device 40 on a specific frequency of transmission of sensor information. Once transmission is complete, the server 10 terminates the transmission frequency control process.

[0606] On the other hand, in step S1202, if the PRPL request value acquired in step S1201 is greater than or equal to the first threshold (step S1202: No), the server 10 determines whether the PRPL request value acquired in step S1201 is greater than or equal to the second threshold (step S1204). If the PRPL request value is greater than or equal to the second threshold (step S1204: Yes), the server 10 transmits a request to the terminal device 40 to reduce the frequency of transmission of sensor information (step S1205). The server 10 may instruct the terminal device 40 on the specific frequency of transmission of sensor information. Once transmission is complete, the server 10 terminates the transmission frequency control process.

[0607] On the other hand, if the requested PRPL value is less than the second threshold or equal to or less than the second threshold (step S1204: No), the server 10 ends the transmission frequency control process.

[0608] Here, the frequency of transmitting sensor information does not necessarily have to match the frequency of detecting sensor information by the sensor unit 46. For example, the frequency of transmitting sensor information to the server 10 may depend on the request for PRPL / RPL, and the frequency of detecting sensor information by the sensor unit 46 may depend on the request for MPL (Motion to Photon Latency). As described above, in order to provide the user with the QoE required for a service for an XR application, a Motion to Photon Latency (MPL) of 20 ms or less is required. Furthermore, depending on the type of XR application and the XR media content being handled, a PRPL / RPL of, for example, approximately 50 ms to 200 ms is required. In other words, the frequency of transmitting sensor information can be lower than the frequency of detecting sensor information.

[0609] The server 10 may change information related to the traffic pattern of the uplink data flow in accordance with the request to increase the transmission frequency in step S1203. Then, the server 10 may request the TSCTSF 551 to change the TSC support container via the AF 548 using a service provided by the NEF 542, for example, the Nnef_AFsessionWithQoS_Update service.

[0610] Furthermore, in accordance with the request to increase the transmission frequency in step S1203, the server 10 may request the setting or update of a Configured Grant (CG) having a periodicity corresponding to the transmission frequency related to the increase request. In this case, the periodicity may be the periodicity corresponding to the transmission frequency requested by the server 10 to the core network CN via the AF 548. For example, the modified TSC support container includes an instruction to request the setting or update of a CG having a periodicity corresponding to the transmission frequency related to the increase request.

[0611] In addition, in accordance with the transmission frequency reduction request in step S1205, the server 10 may request the establishment or update of a CG having a cycle corresponding to the transmission frequency related to the reduction request. In this case, the cycle may be the cycle corresponding to the transmission frequency that the server 10 requests from the core network CN via the AF 548. For example, the modified TSC support container includes an instruction to request the establishment or update of a CG having a cycle corresponding to the transmission frequency related to the reduction request.

[0612] The server 10 can request the establishment or update of a CG via policy control. For example, the server 10 requests the PCF 545 to create a policy for establishing or updating a CG in accordance with the period of uplink data bursts included in the TSC support information. In this case, the server 10 can use the service provided by the NEF 542 to invoke the Npcf_UEPolicyControl_Create / Update service provided by the PCF 545 via the AF 548.

[0613] When the core network CN receives a request to set or update a CG from the AF 548, it instructs the base station 30 to set or update a CG for the QoS flow (uplink QoS flow) allocated for transmitting sensor information.

[0614] The base station 30 acquires information related to the CG period included in the CG setting or update instruction. Alternatively, the base station 30 acquires information related to the CG period from the TSC support information. The base station 30 then assigns a CG with that period to the terminal device 40, which is an XR device. The terminal device 40 periodically transmits sensor information to the server 10 using the CG assigned by the base station 30.

[0615] Furthermore, the base station 30 may configure the terminal device 40 for discontinuous transmission (DTX) in accordance with the CG period. The base station 30 configures a period including resources for which a CG is configured as an active period, and configures other periods as inactive periods. In other words, the inactive period of DTX becomes longer as the frequency of transmission of sensor information decreases. The server 10 may request the core network CN to configure or update this DTX in addition to configuring or updating the CG. For example, the modified TSC support container includes an instruction to request the configuration or update of DTX in accordance with the configuration or update of the CG.

[0616] The server 10 can request the setting or update of DTX via policy control. For example, the server 10 requests the PCF 545 to create a policy for setting or updating DTX in accordance with the setting or update of the CG. In this case, the server 10 may use a service provided by the NEF 542 to invoke the Npcf_UEPolicyControl_Create / Update service provided by the PCF 545 via the AF 548.

[0617] Furthermore, when the base station 30 does not configure a CG, it may configure DTX for the terminal device 40 based on TSC support information for the uplink QoS flow. The base station 30 may configure DTX corresponding to the period included in the TSC support information. This allows the base station 30 to configure the active period of DTX based on the survival time included in the TSC support information.

[0618] The base station 30 allocates resources to the terminal device 40 so that all PDU packets included in each data burst of the QoS flow can be transmitted within the period of each data burst.

[0619] The base station 30 sets the DTX so that the period of each data burst is included in the active period, thereby setting the period other than the period of each data burst as an inactive period.

[0620] Through the above processing, the server 10 controls the frequency of transmission of sensor information according to the magnitude / speed of change in the video or the magnitude of change or movement of 2D / 3D content multiplexed onto the video relative to the video, thereby enabling sensor information to be acquired at an appropriate frequency. Furthermore, the server 10 can improve the reliability of sensor information acquisition by assigning a CG with a period corresponding to the transmission frequency. Furthermore, the server 10 can achieve low power consumption by controlling the DTX inactive period set in the terminal device 40 in accordance with the control of the frequency of transmission of sensor information.

[0621] 5-7. Sixth Example Next, a sixth example will be described. In the sixth example, control of the update frequency (transmission frequency) of sensor information and the update frequency (reception frequency) of XR media content will be described.

[0622] As described above, the frequency of transmitting sensor information to the server 10 depends on requests for PRPL (Pose to Render to Photon Latency) / RPL (Render to Photon Latency), and the frequency of detecting sensor information in the sensor unit 46 depends on requests for MPL (Motion to Photon Latency). Furthermore, the frame rate of XR media on the display unit 451 of the terminal device 40 depends on requests for MPL (Motion to Photon Latency). Therefore, for example, a frame rate of 60 fps (frames per second) is used for requests for MPL (Motion to Photon Latency) of 20 ms or less. At 60 fps, the time per frame is 16.7 ms (= 1000 ms / 60). The term "PRPL" used in this embodiment can be replaced with "RPL."

[0623] FIG. 27 is a diagram showing an example of a timing chart related to control for displaying XR media on the terminal device 40. The server 10 determines the update frequency of XR media content to the terminal device 40 based on the request to PRPL. For example, if the request to PRPL is 75 ms, a delay four times 60 fps (= 16.67 × 4 = 66.67 ms) is allowed. In this case, the server 10 sets the update frequency of the XR media content to the terminal device 40 to, for example, a period four times 60 fps (= 16.67 × 4 = 66.67 ms). Furthermore, the server 10 determines the transmission frequency of sensor information from the terminal device 40 to the server 10 based on the request to PRPL. For example, the server 10 sets the transmission frequency of sensor information from the terminal device 40 to the server 10 to the same period as the update frequency of the XR media content to the terminal device 40 (four times 60 fps).

[0624] Here, the server 10 may notify the terminal device 40 of information on the update frequency (third cycle) of the XR media content and information on the transmission frequency (second cycle) of the sensor information via the AF 548 as a request to the terminal device 40. The server 10 may also notify the terminal device 40 of information on the detection frequency (first cycle) of the sensor information by the terminal device 40.

[0625] In accordance with the request from the MPL, the terminal device 40 sets the frequency of detection of sensor information by the sensor unit 46 to a period equal to or shorter than the frame period (e.g., 16.67 ms) of the XR media on the display unit 451. For example, the terminal device 40 may set the frequency of detection of sensor information by the sensor unit 46 to the same frequency (e.g., 60 fps) as the frame rate of the XR media on the display unit 451. The terminal device 40 may set this frequency of detection of sensor information (first period) in accordance with a request (notification) from the server 10 via the AF 548. In this case, the server 10 may determine the frequency of detection of sensor information (first period) based on information about the frame period. The terminal device 40 may dynamically control the frame rate of the XR media. For example, the terminal device 40 may control the frequency of detection of sensor information by the sensor unit 46 to match the frame rate of the XR media.

[0626] The sensor unit 46 of the terminal device 40 detects sensor information #1 at sensing timing #1. The terminal device 40 also receives XR media content #1 from the server 10 at XR media content reception timing #1.

[0627] The terminal device 40 (for example, the XR display area rendering unit 76 of the XR device 70) performs a display (rendering) process using time warp on the detected sensor information #1 and the received XR media content #1. The terminal device 40 then displays the rendered image at frame timing #1 of the XR media on the display unit 451.

[0628] In addition, if the update frequency (third period) of the XR media content is greater than the frame period of the XR media content, the server 10 may notify the terminal device 40 of an instruction to generate a frame image to interpolate the XR media content at a predetermined timing of the frame period.

[0629] At this time, the terminal device 40 performs a display (rendering) process using time warp based on the detected sensor information #2 and the received XR media content #1. Then, the terminal device 40 displays the rendered image at frame timing #2 of the XR media on the display unit 451. In other words, the terminal device 40 interpolates the image to be displayed at frame timing #2 through a display process using time warp.

[0630] Similarly, the terminal device 40 performs a display (rendering) process using time warp based on the detected sensor information #3 and #4 and the received XR media content #1. The terminal device 40 then displays the rendered images at frame timings #3 and #4 of the XR media on the display unit 451. In other words, the terminal device 40 interpolates the images to be displayed at frame timings #3 and #4 through a display process using time warp.

[0631] Of course, the terminal device 40 may interpolate the XR media content even when there is no instruction from the server 10.

[0632] Next, the sensor unit 46 of the terminal device 40 detects sensor information #5 at sensing timing #5. Then, the terminal device 40 receives XR media content #2 from the server 10 at XR media content reception timing #2.

[0633] The terminal device 40 (for example, the XR display area rendering unit 76 of the XR device 70) performs a display (rendering) process using time warp based on the detected sensor information #5 and the received XR media content #2. The terminal device 40 then displays the rendered image at frame timing #5 of the XR media on the display unit 451.

[0634] Here, the server 10 requests the TSCTSF 551 to generate a TSC support container using a service provided by the NEF 542, for example, the Nnef_AFsessionWithQoS_Create service. In this case, the server 10 may use the Nnef_AFsessionWithQoS_Create service via the AF 548.

[0635] The TSCTSF 551 generates a TSC support container for an uplink QoS flow (hereinafter also referred to as an uplink TSC support container). At this time, the TSCTSF 551 generates an uplink TSC support container whose period is the frequency of transmission of sensor information to the server 10.

[0636] The TSCTSF 551 generates a TSC support container for a downlink QoS flow (hereinafter also referred to as a downlink TSC support container). At this time, the TSCTSF 551 generates a downlink TSC support container whose period is the update frequency of the XR media content to the terminal device 40.

[0637] In addition, the SMF 546 updates the TSC support information for the target QoS flow using the Burst Arrival Time (BAT) offset fed back from the base station 30 .

[0638] As described above, the terminal device 40 may control the frequency of detecting sensor information in accordance with the frame rate of the XR media. In this case, the communication device may include in the request an instruction to set the TSC support information for the QoS flow (uplink QoS flow) for transmitting sensor information in accordance with the TSC support information for the QoS flow (downlink QoS flow) for updating the XR media content. For example, the communication device utilizes the BAT offset fed back from the base station 30 to update the burst arrival time of the TSC support information for the target downlink QoS flow, and also updates the burst arrival time of the TSC support information for the QoS flow (uplink QoS flow) for transmitting sensor information.

[0639] The server 10 may also request the core network CN to set or update a CG for a QoS flow (uplink QoS flow) allocated for transmitting sensor information via the AF 548. For example, the updated TSC assistance information includes an instruction to request setting or updating of a CG in accordance with the updated burst arrival time for the uplink QoS flow.

[0640] The server 10 can request the setting or update of a CG via policy control. For example, the server 10 requests the PCF 545 to create a policy for setting or updating a CG in accordance with information related to uplink data bursts (burst arrival time and period) included in the TSC assistance information. In this case, the server 10 can request the setting or update of a CG via the AF 548 using a service provided by the NEF 542 for invoking the Npcf_UEPolicyControl_Create / Update service provided by the PCF 545.

[0641] When the core network CN receives a request to set or update a CG from AF548, it instructs the base station 30 to set or update a CG for the QoS flow (uplink QoS flow) assigned to transmit sensor information.

[0642] The base station 30 acquires information regarding the CG period included in the CG setting or update instruction, or information regarding the period included in the TSC support information for the uplink QoS flow. Then, the base station 30 assigns a CG with that period to the terminal device 40, which is an XR device. Furthermore, the base station 30 may set the position of the first radio resource of the CG to be assigned in accordance with the burst arrival time included in the TSC support information. Also, for example, when the burst arrival time in the TSC support information is updated according to the BAT offset fed back from the base station 30, the base station 30 resets the position of the first radio resource of the CG in accordance with the updated burst arrival time.

[0643] The server 10 may also request the core network CN via the AF 548 to set or update configured scheduling (CS) for a QoS flow (downlink QoS flow) assigned to the terminal device 40 for receiving XR media content. This CS is also called semi-persistent scheduling (SPS). For example, the TSC support information includes an instruction to request setting or updating of CS in accordance with information related to data bursts (burst arrival time and period) for the downlink QoS flow.

[0644] The server 10 can request the establishment or update of the CS via policy control. For example, the server 10 requests the PCF 545 to create a policy for establishing or updating the CS in accordance with information related to downlink data bursts (burst arrival time and period) included in the TSC assistance information. In this case, the server 10 can request the establishment or update of the CS via the AF 548 using a service provided by the NEF 542 for invoking the Npcf_UEPolicyControl_Create / Update service provided by the PCF 545.

[0645] When the core network CN receives a request to set or update the CS from the AF 548, it instructs the base station 30 to set or update the CS for the QoS flow (downlink QoS flow) assigned to the terminal device 40 for receiving XR media content.

[0646] The base station 30 acquires information regarding the CS period included in the CS setting or update instruction, or information regarding the period included in the TSC support information for the downlink QoS flow. The base station 30 then assigns a CS with that period to the QoS flow in order to receive some or all of the data flows of the QoS flow of the target terminal device 40. Furthermore, the base station 30 may set the position of the leading radio resource of the CS to be assigned in accordance with the burst arrival time included in the TSC support information. Furthermore, for example, if the burst arrival time of the TSC support information is updated according to the BAT offset fed back from the base station 30, the base station 30 resets the position of the leading radio resource of the CS in accordance with the updated burst arrival time.

[0647] Furthermore, as described above, if the frame period of the XR media is not an integer multiple of the smallest unit of radio resources allocated by the base station 30, an accumulated error occurs between the CG set to match the frame period and the transmission timing of uplink traffic including tracking and sensor information.

[0648] The terminal device 40 may measure this accumulated error, and if the accumulated error exceeds a preset threshold, may issue an instruction to change the timing of the CG to the base station 30. This instruction to change the timing of the CG may be notified to the base station 30 via RRC (Radio Resource Control) signaling, and may include an offset value that compensates for the accumulated error.

[0649] When the base station 30 receives the offset value for compensating for the accumulated error from the terminal device 40, the base station 30 resets the radio resources to which the CG is allocated in order to compensate for the accumulated error.

[0650] Similarly, for a CS set in accordance with the frame period, the terminal device 40 may measure the cumulative error in the downlink, and if it exceeds a predetermined threshold, may notify the base station 30 of an instruction to change the timing of the CS.

[0651] Through the above control, the server 10 can set the update frequency (transmission frequency) of the sensor information and the update frequency (reception frequency) of the XR media content to a frequency different from the frame period of the XR media on the display unit 451. If the server 10 can relax the requirements for the PRPL depending on the type of XR application and / or XR media content being handled, it may reduce the update frequency (transmission frequency) of the sensor information and / or the update frequency (reception frequency) of the XR media content. For example, the server 10 may reduce the update frequency (transmission frequency) of the sensor information and / or the update frequency (reception frequency) of the XR media content below a predetermined threshold. This allows for reduced power consumption of the terminal device 40.

[0652] Furthermore, the server 10 may request another network device (for example, the base station 30 / core network CN) to set discontinuous transmission (DTX) to the terminal device 40. At this time, the server 10 may request the other network device to set a configured grant (CG) of a second period for the QoS flow assigned for transmitting the sensor information.

[0653] The base station 30 may set DTX on the terminal device 40 in accordance with a request from the server 10 via the AF 548. The base station 30 may set a period including resources for which a CG is set as an active period, and set other periods as inactive periods. The server 10 may control the DTX inactive period in accordance with the transmission frequency (second cycle) of the sensor information. For example, if the transmission frequency of the sensor information can be lowered below a predetermined threshold, the DTX inactive period may be set longer than the predetermined threshold. This achieves further reduction in power consumption.

[0654] In addition, when the position of the first radio resource of a CG is reconfigured in response to an update of the burst arrival time included in the TSC support information for an uplink QoS flow, the base station 30 may reconfigure the DTX active period to include the resource of the reconfigured CG.

[0655] Furthermore, when the base station 30 does not configure a CG, it may configure DTX for the terminal device 40 based on TSC support information for the uplink QoS flow. The base station 30 may configure DTX corresponding to a period included in the TSC support information. The base station 30 may configure the active period of DTX based on a survival time included in the TSC support information.

[0656] The base station 30 may acquire information on packet delay variation for uplink QoS flows from the PCF 545. Then, the base station 30 may set the DTX active period based on the acquired information. Alternatively, the base station 30 may acquire information on jitter for uplink QoS flows from the SMF 546 as a result of traffic parameter measurement. Then, the base station 30 may set the DTX active period based on the acquired information. Here, setting the DTX active period based on the acquired information is performed, for example, by changing the DTX cycle or adding a positive or negative offset to the start timing of the DTX active period so as to correct the acquired packet delay variation or jitter.

[0657] Furthermore, the server 10 may request another network device (e.g., the base station 30 / core network CN) to set discontinuous reception (DRX) to the terminal device 40. At this time, the base station 30 may set discontinuous reception (DRX) to the terminal device 40 in accordance with the request from the server 10 via the AF 548. At this time, the server 10 may request the other network device to set configured scheduling (CS) of a third period for the QoS flow assigned to receive XR media content.

[0658] The base station 30 may configure DRX in the terminal device 40 based on the TSC support information for the downlink QoS flow. The base station 30 may configure DRX corresponding to the period included in the TSC support information. The base station 30 may also configure the DRX active period based on the lifetime included in the TSC support information. The base station 30 may also configure the start timing of the DRX active period based on the burst arrival time.

[0659] Furthermore, it is assumed that the base station 30 receives TSC assistance information in which the burst arrival time is updated according to the BAT offset, as shown in the first embodiment, for example. In this case, the base station 30 may change the setting of the DRX active period based on the updated burst arrival time.

[0660] The base station 30 may acquire packet delay variation for the downlink QoS flow from the PCF 545. Then, the base station 30 may set the DRX active period based on the acquired information. Alternatively, the base station 30 may acquire jitter information for the downlink QoS flow as a result of traffic parameter measurement from the SMF 546. Then, the base station 30 may set the DRX active period based on the acquired information. Here, the setting of the DRX active period based on the acquired information is performed by changing the DRX cycle or adding a positive or negative offset to the start timing of the DRX active period so as to correct the acquired packet delay variation or jitter.

[0661] The base station 30 allocates resources to the terminal device 40 so that all PDU packets included in each data burst of the QoS flow can be transmitted within the period of each data burst.

[0662] The base station 30 sets the DRX so that the period of each data burst is included in the active period, and sets the period other than the period of each data burst as the inactive period.

[0663] When the base station 30 configures the CS to transmit some or all of the PDU packets included in each data burst, the base station 30 configures the period including the resource for which the CS is configured as the active period. The base station 30 then configures the remaining period as the inactive period. The server 10 may control the DRX inactive period in accordance with the reception frequency (third cycle) of the XR media content. For example, if the reception frequency of the XR media content can be lowered below a predetermined threshold, the DRX inactive period may be set longer than the predetermined threshold. This achieves further power consumption reduction.

[0664] Also, as described above, when the position of the first radio resource of the CS is reset according to the updated burst arrival time, the base station 30 may reset the DRX so that the period including the reset CS resource is included in the active period.

[0665] The server 10 may request the base station 30 to set the same DTX and DRX cycles for the terminal device 40. Alternatively, the server 10 may request the base station 30 to independently set different DTX and DRX cycles for the terminal device 40.

[0666] Furthermore, when the server 10 requests the base station 30 to set DTX and DRX with the same cycle, the server 10 may provide the base station 30 / terminal device 40 with information on the offset period between DTX and DRX.

[0667] At this time, the server 10 may set this offset period taking into account the packet delay budget (PDB) allocated to the uplink QoS flow. Alternatively, the server 10 may set this offset period taking into account the PDB allocated to the downlink QoS flow. Alternatively, the server 10 may set this offset period taking into account the measurement results of packet delay for the uplink QoS flow. Alternatively, the server 10 may set this offset period taking into account the measurement results of packet delay for the downlink QoS flow. Alternatively, the server 10 may set this offset period in accordance with the RPL.

[0668] That is, the server 10 may change this offset period according to the PDB assigned to the uplink QoS flow, the PDB assigned to the downlink QoS flow, the measurement results of the packet delay of the uplink QoS flow, the measurement results of the packet delay of the downlink QoS flow, or a change in the RPL.

[0669] Also, assume that the base station 30 receives a notification of the End PDU of the PDU set included in the PDU set information. In this case, the base station 30 may transmit the notification of the End PDU of the PDU set to the terminal device 40 using DCI (Downlink Control Information). The terminal device 40 that has received the notification of the End PDU of the PDU set may transition to an inactive period in priority to DRX control. This control may be valid until the timing of transition from the next DRX active period to the inactive period. In this case, the terminal device 40 may enter an active state at the timing of transition from the next DRX inactive period to the active period.

[0670] Alternatively, the base station 30 may use the DCI to transmit an early DRX transition instruction to the terminal device 40 instead of notifying the End PDU of the PDU set. The terminal device 40 that has received the early DRX transition instruction may transition to the inactive period prior to the timing of transition from the active period to the inactive period under DRX control.

[0671] Furthermore, as shown in the above-described embodiment, the base station 30 may allocate radio resources to only X% (e.g., 75%) of the PDUs of the PDU set in accordance with the PDU set aggregation processing information, among all the PDUs in the PDU set. Then, when discarding the remaining PDUs, the base station 30 may transmit an early DRX transition instruction to the terminal device 40 after transmitting all the PDUs to which radio resources have been allocated.

[0672] This control enables the terminal device 40 to operate with even lower power consumption depending on the reception status of the burst data or PDU set.

[0673] <5-8. Seventh Example> Next, the XR media distribution process of the seventh example will be described. As described above, the XR media distribution process is divided into a session establishment process and a setting process. The session establishment process is the same as the session establishment process according to the first example, so a description thereof will be omitted. Below, the setting process according to the seventh example will be described.

[0674] Fig. 28 is a flowchart showing an example of the setting process according to the seventh embodiment. The setting process according to the seventh embodiment will be described below with reference to the flowchart of Fig. 28.

[0675] The server 10 requests another network device (e.g., a core network CN) to set QoS monitoring including measurement of uplink (UL) and downlink (DL) packet delays via the AF 548 (step S1301). The server 10 receives a report including measurement results of UL and DL packet delays from the other network device (step S1302).

[0676] The server 10 increases the resolution by one level (step S1303). Then, the server 10 calculates the processing time PT for the resolution and / or codec that are the setting candidates. Ｓｅｒｖｅｒ is calculated (step S1304).

[0677] The server 10 receives the measurement results of the UL packet delay, the measurement results of the DL packet delay, and the calculated PT Ｓｅｒｖｅｒ Based on this, the Pose to Render to Photon Latency (PRPL) is calculated (step S1305). The term "PRPL" used in this embodiment can be replaced with "RPL".

[0678] The server 10 determines whether the calculated PRPL is equal to or less than the required value for the XR application (step S1306). If the calculated PRPL is equal to or less than the required value for the XR application (step S1306: Yes), the server 10 executes the processes from step S1303 onward again.

[0679] On the other hand, if the calculated PRPL exceeds the required value for the XR application (step S1306: No), the server 10 lowers the resolution by one level (step S1307). The server 10 then sets the candidate resolution and codec as the resolution and codec to be used to generate the XR media content (step S1308). The server 10 may set only one of the resolution and codec. Once the settings are complete, the server 10 terminates the setting process.

[0680] The measurement results of UL and DL packet delays acquired in step S1302 may be measurement results of RT (Round Trip) packet delays. Ｓｅｒｖｅｒ The PRPL may be calculated based on the following:

[0681] In this embodiment, the PDB, which is the upper limit of the packet delay in the UL and DL shown in FIG. ＵＬ , and PDB ＤＬ The resolution is set based on the resolution set based on the above, and the resolution is set according to the actual UL and DL packet delays. This makes it possible to dynamically generate XR media with the optimal resolution.

[0682] Note that the above-described alternative method for step S609 can also be applied to step S1307.

[0683] 5-9. Eighth Example Next, an XR media distribution process according to an eighth example will be described. In the eighth example, a switch for setting a resolution and / or a codec during handover will be described.

[0684] When the base station 30 providing the uplink and downlink QoS flows to the terminal device 40 is switched due to handover, there is a concern that discontinuity may occur in packet delay. This may cause discontinuity in the calculated PRPL (Pose to Render to Photon Latency). Therefore, the server 10 avoids discontinuity in PRPL before and after switching the base station 30 by performing the following switching process.

[0685] 29 is a flowchart showing the setting process according to the eighth embodiment. The setting process according to the eighth embodiment will be described below with reference to the flowchart of FIG.

[0686] The server 10 detects that handover processing for the terminal device 40 has started (step S1401). At this time, the server 10 may detect that handover processing has started when it receives a notification regarding the handover processing from the core network CN. Here, the notification regarding the handover processing is, for example, a notification from the core network CN that the terminal device 40 has started an event-triggered measurement report.

[0687] When the server 10 detects the start of the handover process, it switches the resolution and / or codec setting method for generating the XR media content from a method using packet delay measurement results (hereinafter referred to as the first method) to a method using a packet delay budget (PDB) (hereinafter referred to as the second method) (step S1402). Here, the first setting method is, for example, the method described using FIG. 28. The second setting method is, for example, the method described using FIG. 17, FIG. 20, FIG. 22, FIG. 23, or FIG. 25.

[0688] The server 10 calculates the PRPL and MDBV according to the method using the PDB (second method). ＤＬ The server 10 sets the resolution and codec accordingly (step S1403). Note that the server 10 may set only one of the resolution and codec. The term "PRPL" used in this embodiment can be replaced with "RPL".

[0689] When the server 10 detects that the handover process for the terminal device 40 has ended (step S1404), it switches the resolution and / or codec setting method for generating XR media content from a method using PDB (second method) to a method using packet delay measurement results (first method) (step S1405). Thereafter, the server 10 sets the resolution and / or codec according to the first setting method until the next handover process. When the switch is complete, the server 10 ends the setting process.

[0690] Through the above control, the server 10 can switch the PRPL calculation method to a method of calculating the PRPL using the PDB, which is the upper limit of packet delay, before switching the base station 30 due to handover. As a result, the server 10 can avoid discontinuity in the PRPL before and after switching the base station 30, and can set an appropriate resolution and / or codec as the resolution and / or codec for generating the XR media content.

[0691] 5-10. Ninth Example Next, an XR media distribution process according to a ninth example will be described. In the ninth example, a process for setting the resolution and / or codec during handover will be described.

[0692] When the current source base station 30, which is providing uplink and downlink QoS flows to the terminal device 40, is switched to a target base station 30, the target base station 30 may not be able to provide the same QoS flows as the source base station 30. For example, if the source base station 30 supports an edge server while the target base station 30 does not support an edge server, it may be difficult for the target base station 30 to provide the same QoS flows as the source base station 30. In this case, visual discontinuity may occur in the video displayed on the terminal device 40 before and after the base station 30 is switched. Therefore, the server 10 reduces the visual discontinuity in the video before and after the base station 30 is switched by the following switching process.

[0693] 30 is a flowchart showing the setting process according to the ninth embodiment. The setting process according to the ninth embodiment will be described below with reference to the flowchart of FIG.

[0694] When the server 10 detects that handover processing for the terminal device 40 has started (step S1501), the server 10 switches from a method using packet delay measurement results (hereinafter referred to as the first method) to a method using a PDB (Packet Delay Budget) (hereinafter referred to as the second method) (step S1502). Here, the first setting method is, for example, the method described using FIG. 28. The second setting method is, for example, the method described using FIG. 17, FIG. 20, FIG. 22, FIG. 23, or FIG. 25.

[0695] The server 10 acquires the MDBV (Maximum Data Burst Volume) and / or PDB of the QoS flow at the handover destination to be provided to the terminal device 40 (step S1503).

[0696] The server 10 calculates the upper limit of the PRPL based on the PBD of the current QoS flow (hereinafter referred to as the first PDB) and the PBD of the QoS flow at the handover destination (hereinafter referred to as the second PDB) (step S1504). At this time, the server 10 may use the PDB with the larger delay between the first PBD and the second PBD to calculate the upper limit of the PRPL. The term "PRPL" used in this embodiment can be replaced with "RPL."

[0697] The server 10 identifies the smaller MDBV between the first MDBV and the second MDBV (step S1505).

[0698] The server 10 sets the resolution and / or codec in accordance with the calculated upper limit of PRPL and the identified MDBV (step S1506).

[0699] With the above control, before the base station is switched during handover, the terminal device 40 obtains the maximum data burst amount and PDB of the QoS flow that the target base station provides to the terminal device 40, and the server 10 sets the resolution and codec based on the larger PDB and smaller maximum data burst amount, which is expected to reduce visual discontinuity in the video displayed before and after the base station is switched.

[0700] <<6. Modifications>> The above-described embodiment is merely an example, and various modifications and applications are possible.

[0701] 6-1. Modifications Related to Distribution of XR Media Content In the above-described embodiment, an example of distributing one video was shown as an example of distributing XR media content. However, this embodiment is not limited to this. For example, if the terminal device 40 is a glasses-type wearable device, the server 10 may distribute two different videos for the left and right eyes. Here, the server 10 may process these two different videos as synchronized videos.

[0702] At this time, the core network CN may determine whether the terminal device 40 has the capability to receive two synchronized videos in the XR media content distribution service based on the UE radio capability ID held by the UCMF 550.

[0703] The PCF 545 may maintain a PCC rule for receiving two synchronized videos. The PCF 545 may then apply this PCC rule to a PDU session established for a device capable of receiving two synchronized videos. In this PCC rule, a TSC QoS flow is assigned to the established PDU session. In this PCC rule, at least two PDU sets are configured for transmitting data of the two synchronized videos for one data burst. Each PDU in one PDU set may be assigned a packet of data for a frame image for the left eye. Each PDU in the other PDU set may be assigned a packet of data for a frame image for the right eye.

[0704] The server 10 may have the function of separating the left-eye frame image data and the right-eye frame image data into three pieces of video data: identical video data between the left-eye frame image data and the right-eye frame image data (hereinafter referred to as first video data), differential data between the first video data and the left-eye frame image data (hereinafter referred to as second video data), and differential data between the first video data and the right-eye frame image data (hereinafter referred to as third video data). In this case, the PCF 545 may hold PCC rules for receiving three synchronized pieces of video data.

[0705] To transmit three synchronized video data, the server 10 may request the core network CN to set three PDU sets for one data burst via AF 548. The server 10 may then assign the first video data to a PDU in the first PDU set, the second video data to a PDU in the second PDU set, and the third video data to a PDU in the third PDU set, and transmit them within the same data burst. This reduces the amount of frame image data to be transmitted.

[0706] The server 10 may request the setting of these three PDU sets for one TSC QoS flow, or may request the setting of each PDU set for each of three TSC QoS flows for which TSC support information including the same parameters is set.

[0707] When each frame image is divided into multiple images with different priorities, the server 10 may assign different priorities to the PDUs in each PDU set set for the multiple PDUs that make up one data burst, depending on the priority of the image. The server 10 may assign PDUs with different priorities to packets of data of the divided frame images, depending on the priority of the image.

[0708] Alternatively, when each frame image is divided into multiple images with different priorities, the server 10 may set multiple PDU sets for the multiple PDUs that make up one data burst, instead of setting one PDU set for each PDU. The server 10 may then assign different priorities to the multiple PDU sets depending on the priorities of the images. For example, the server 10 may assign packets of the divided frame images to PDUs of PDU sets with different priorities depending on the priorities of the images.

[0709] Here, the various processes shown in the above-mentioned embodiments can also be applied to the transmission of data of two synchronized moving images.

[0710] 6-2. Modifications Related to System Configuration / Device Configuration The server 10 does not necessarily have to be configured with a single information processing device. The server 10 may be configured with multiple information processing devices. Some or all of the processing on the server 10 may be distributed to multiple devices, including a cloud server, an application server, and an edge server.

[0711] A part of the processing in the server 10 may be implemented in an edge application server. In this case, the edge application server may be connected to a session including a cloud server or an application server via an L-PSA (Local PDU Session Anchor) UPF 520 in a session breakout connection form.

[0712] When all the processes of the server 10 are implemented in an edge application server, the edge application server may be connected to the session via the L-PSA UPF 520 in a distributed anchor point connection topology.

[0713] For example, the SMF 546 may initiate a process to implement part or all of the processing of the server 10 in an edge application server in accordance with a request from the AF 548. Alternatively, a process to implement part or all of the processing of the server 10 in an edge application server may be initiated in accordance with information identifying a network slice included in a request to establish a PDU session. In this case, for example, the SMF 546 may acquire a policy corresponding to the information identifying the network slice from the PCF 545. Then, the SMF 546 may initiate a process to implement part or all of the processing of the server 10 in an edge application server in accordance with the acquired policy.

[0714] In addition, if the 5QI of the QoS flow assigned to the PDU session to be established is a specific 5QI, the device processing the acquired policy may instruct the edge application server to implement some or all of the processing of server 10.

[0715] When the SMF 546 determines that the CN PDB of the 5QI allocated to the PDU session is not satisfied, the SMF 546 may initiate a process to implement part or all of the processing of the server 10 in the edge application server. In this case, the SMF 546 may obtain a report that the CN PDB is not satisfied from the base station 30. Alternatively, the SMF 546 may detect that the CN PDB is not satisfied through QoS monitoring.

[0716] The SMF 546 may identify the UPF 520 and the edge application server that will become the L-PSA based on the location information of the terminal device 40 and / or the base station 30. Alternatively, the L-PSA UPF 520 and the edge application server that correspond to the base station 30 may be set in advance in the core network CN.

[0717] Here, the SMF 546 may identify the connection between the L-PSA UPF 520 and the edge application server by a Data Network Access Identifier (DNAI). Note that one or more DNAIs may be set for a combination of an application or a DNN and an S-NSSAI.

[0718] The SMF 546 may select one DNAI based on information related to the location of the terminal device 40 or information identifying the base station 30 to which the terminal device 40 is connected. The SMF 546 may identify the connection between the L-PSA UPF 520 and the edge application server corresponding to the selected DNAI.

[0719] 6-3. Other Modifications The server 10, management device 20, base station 30, or control device that controls the terminal device 40 of this embodiment may be realized by a dedicated computer system or a general-purpose computer system.

[0720] For example, a program for executing the above-described operations may be stored and distributed on a computer-readable recording medium such as an optical disk, a semiconductor memory, a magnetic tape, or a flexible disk. Then, for example, the program may be installed on a computer and the above-described process may be executed to configure a control device. In this case, the control device may be a device (e.g., a personal computer) external to the server 10, the management device 20, the base station 30, or the terminal device 40. Alternatively, the control device may be a device (e.g., the control unit 13, the control unit 23, the control unit 33, or the control unit 43) internal to the server 10, the management device 20, the base station 30, or the terminal device 40.

[0721] The communication program may also be stored in a disk device provided in a server device on a network such as the Internet, and may be downloaded to a computer. The above-described functions may also be realized by a combination of an operating system (OS) and application software. In this case, the components other than the OS may be stored on a medium and distributed, or may be stored in a server device and downloaded to a computer.

[0722] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method. In addition, the information including the processing procedures, specific names, various data, and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified. For example, the various information shown in each drawing is not limited to the information shown in the drawings.

[0723] Furthermore, the components of each device shown in the figure are conceptual functional components and do not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc.

[0724] The above-described embodiments can be combined as appropriate within the scope of the present invention without causing any inconsistency in the processing content. The order of the steps shown in the sequence diagrams or flowcharts of the present embodiment can be changed as appropriate.

[0725] Furthermore, for example, the present embodiment can also be implemented as any configuration that constitutes an apparatus or system, such as a processor as a system LSI (Large Scale Integration), a module using multiple processors, a unit using multiple modules, a set in which other functions are added to a unit, or the like (i.e., a configuration of a part of an apparatus).

[0726] In this embodiment, a system refers to a collection of multiple components (devices, modules (components), etc.), regardless of whether all of the components are in the same housing. For example, multiple devices housed in separate housings and connected via a network, etc., and a single device in which multiple modules are housed in a single housing are both systems.

[0727] Furthermore, for example, this embodiment can have a cloud computing configuration in which one function is shared and processed jointly by a plurality of devices via a network.

[0728] <<7. Conclusion>> As described above, according to this embodiment, the server 10 identifies delay request information related to reflecting a user's actions in the XR media. For example, the server 10 identifies a request value selected from multiple request values ​​of PRPL (Pose to Render to Photon Latency) or RPL (Render to Photon Latency) according to an application related to the XR media (hereinafter referred to as the XR application) as delay request information. Furthermore, the server 10 acquires tolerance information (e.g., PDB (Packet Delay Budget)) related to the transmission delay of the Quality of Service (QoS) flow assigned to the session established for the XR application. The XR server makes a decision regarding the generation of XR media content to be transmitted to the terminal device 40 (determines the resolution and / or codec of the XR media content) based on the delay request information and the tolerance information.

[0729] This allows the server 10 to selectively set an appropriate resolution and / or codec for each of multiple XR applications with different delay requirements (PRPL or RPL requirements) for reflecting user actions. As a result, the server 10 can generate XR media content that matches the QoS flow assigned to the session. As a result, stable, low-latency wireless transmission of XR media content is achieved even in a dynamically changing wireless environment.

[0730] The server 10 also acquires information on the maximum data burst volume (MDBV) of the downlink QoS flow allocated to the session established for the XR application. The server 10 then determines the resolution and / or codec of the XR media content to be transmitted to the terminal device 40 based on the delay request information, tolerance information, and maximum data burst volume information. This allows the server 10 to set a more appropriate resolution and / or codec according to the maximum data burst volume of the allocated QoS flow.

[0731] The server 10 also has a PDB (PDB ＵＬ and PDB ＤＬ The server 10 identifies an image area to be transmitted to the terminal device 40, taking into consideration the display area that moves during the period of time (at least one of the above). The server 10 then determines the resolution and / or codec to be applied to the transmitted data (image area) based on the maximum downlink data burst volume. This allows the server 10 to set a more appropriate resolution and / or codec.

[0732] The server 10 also determines the required value of PRPL or RPL according to the magnitude / speed of changes in the video related to the XR media, or the magnitude of changes or movements in the video of 2D / 3D content multiplexed onto the video, thereby enabling the server 10 to achieve the motion to photon latency (MPL) required to satisfy the user's QoE.

[0733] The server 10 also controls the frequency of sensor information transmission from the terminal device 40 according to the magnitude / speed of changes in the video related to the XR media, changes in the video of 2D / 3D content multiplexed onto the video, or the magnitude of movement. For example, the server 10 requests other network devices (e.g., the base station 30 / core network CN) to allocate a configured grant (CG) with a period corresponding to the transmission frequency to the QoS flow assigned for transmitting the sensor information. This improves the reliability of acquiring the sensor information. Furthermore, the server 10 may control the inactive period of the DTX set in the XR device in accordance with the control of the transmission frequency of the sensor information. This reduces power consumption.

[0734] Furthermore, the server 10 sets the update frequency (transmission frequency) of the sensor information and the update frequency (reception frequency) of the XR media content for the terminal device 40 to a period different from the frame period of the XR media on the display unit 451. For example, if the server 10 can relax the requirements for PRPL or RPL depending on the type of XR application and / or XR media content, it reduces the update frequency (transmission frequency) of the sensor information and the update frequency (reception frequency) of the XR media content. This reduces the power consumption of the terminal device 40.

[0735] The server 10 also determines the PDB, which is the upper limit of the uplink packet delay. ＵＬ and PDB, which is the upper bound on the downlink packet delay. ＤＬ The resolution is set based on the above and is adjusted to match the actual uplink and downlink packet delays, thereby enabling the dynamic generation of XR media with optimal resolution.

[0736] Although the embodiments of the present disclosure have been described above, the technical scope of the present disclosure is not limited to the above-described embodiments, and various modifications are possible within the scope of the gist of the present disclosure. Furthermore, components of different embodiments and modifications may be combined as appropriate.

[0737] Furthermore, the effects of each embodiment described in this specification are merely examples and are not intended to be limiting, and other effects may also be obtained.

[0738] The present technology may also be configured as follows: (1) An information processing device comprising: an identification unit that identifies information on a delay request related to reflection of a user's actions in XR (Extended Reality) video content; an acquisition unit that acquires tolerance information related to a transmission delay of a Quality of Service (QoS) flow assigned to a session established for an application related to the video content; and a decision unit that makes a decision on generation of data related to the video content to be transmitted to a terminal device used by the user, based on the delay request information and the tolerance information. (2) The information processing device described in (1), wherein the tolerance information includes at least one of a first PDB (Packet Delay Budget) of an uplink QoS flow assigned to the session established for the application and a second PDB (Packet Delay Budget) of a downlink QoS flow assigned to the session established for the application, and the decision unit makes a decision on generation of data related to the video content, based on the delay request information and at least one of the first PDB and the second PDB. (3) The information processing device according to (1) or (2), wherein the determination unit determines at least one of a resolution and a codec of the video content as a decision regarding generation of data related to the video content. (4) The information processing device according to any one of (1) to (3), wherein the specification unit specifies, as the information regarding the delay request, a required value selected from a plurality of required values ​​of PRPL (Pose to Render to Photon Latency) or RPL (Render to Photon Latency) according to the application.(5) The information processing device according to any one of (1) to (4), wherein the acquisition unit acquires information on a maximum data burst size of a downlink QoS flow allocated to a session established for the application, and the decision unit makes a decision regarding generation of data related to the video content to be transmitted to the terminal device based on the delay request information, the tolerance information, and the information on the maximum data burst size. (6) The information processing device according to any one of (1) to (4), wherein the acquisition unit acquires information on a maximum data burst size of a downlink QoS flow allocated to a session established for the application, and the decision unit makes a decision regarding generation of data related to the video content to be transmitted to the terminal device based on the delay request information, the tolerance information, and the information on the maximum data burst size. (7) The information processing device according to any one of (1) to (4), wherein the acquisition unit acquires information on a maximum data burst size of a downlink QoS flow allocated to a session established for the application, and the decision unit makes a decision regarding generation of data related to the video content to be transmitted to the terminal device based on the delay request information, the tolerance information, and the information on the maximum data burst size. (8) The information processing device according to any one of (1) to (4), wherein the determination unit determines an area of ​​an image related to the video content to be transmitted to the terminal device based on the tolerance information, and makes a decision regarding generation of data related to the video content to be transmitted to the terminal device based on the delay request information, the tolerance information, and the area information. (9) The information processing device according to (8), wherein the acquisition unit acquires information on a maximum data burst amount of a downlink QoS flow assigned to a session established for the application, and the determination unit makes a decision regarding generation of data related to the video content to be transmitted to the terminal device based on the delay request information, the tolerance information, the area information, and the maximum data burst amount information. (10) The information processing device according to (8) or (9), wherein the acquisition unit acquires sensor information from a sensor provided in the terminal device, and the determination unit determines the area of ​​the image based on the sensor information and the tolerance information.(11) The information processing device according to (10), further comprising: a generation unit that generates an AI (Artificial Intelligence) or ML (Machine Learning) model using the sensor information detected at a plurality of different times, wherein the determination unit determines the region of the image based on information obtained by inputting the sensor information into the AI ​​or ML model. (12) The information processing device according to any one of (1) to (4), further comprising: a detection unit that detects a magnitude or speed of a change in a moving image included in the moving image content, wherein the identification unit identifies information about the delay request based on the magnitude or speed of the change in the moving image, and the determination unit makes a decision regarding generation of data related to the moving image content based on the information about the delay request and the tolerance information. (13) The information processing device according to (12), further comprising: a generation unit that generates an AI (Artificial Intelligence) or ML (Machine Learning) model using the sensor information detected at a plurality of different times, wherein the determination unit determines a transmission frequency of I frames of a GOP (Group of Pictures) of the moving image content based on the magnitude or speed of the change in the moving image. (14) The information processing device according to (12) or (13), wherein the determination unit determines a frame rate of data related to the video content according to a magnitude or speed of change in the video. (15) The information processing device according to any one of (12) to (14), further comprising: a request unit that requests the terminal device to increase or decrease a frequency of transmission of sensor information from a sensor included in the terminal device to the information processing device when the delay request information satisfies a predetermined criterion. (16) The information processing device according to (15), wherein the request unit requests another network device to set or update a Configured Grant (CG) having a period corresponding to the transmission frequency in conjunction with requesting the terminal device to increase or decrease the transmission frequency of the sensor information.(17) The information processing device according to any one of (1) to (4), further comprising: a notification unit that notifies the terminal device of periodic information regarding sensor information used in processing for reflecting user actions in the video content, wherein the determination unit: determines a first period that is a period at which the terminal device detects sensor information based on information about a frame period at which the video content is displayed, determine...

Claims

1. An information processing device comprising: an identification unit that identifies information on a delay request regarding the reflection of a user's actions in XR (Extended Reality) video content; an acquisition unit that acquires tolerance information regarding a transmission delay of a Quality of Service (QoS) flow assigned to a session established for an application related to the video content; and a decision unit that makes a decision regarding the generation of data related to the video content to be transmitted to a terminal device used by the user based on the delay request information and the tolerance information.

2. The information processing device of claim 1, wherein the tolerance information includes at least one of a first PDB (Packet Delay Budget) of an uplink QoS flow assigned to a session established for the application and a second PDB (Packet Delay Budget) of a downlink QoS flow assigned to a session established for the application, and the decision unit makes a decision regarding the generation of data related to the video content based on the delay request information and at least one of the first PDB and the second PDB.

3. The information processing device according to claim 1, wherein the decision unit makes a decision regarding at least one of a resolution and a codec of the video content as a decision regarding the generation of data related to the video content.

4. The information processing device according to claim 1, wherein the determination unit determines a requirement value selected from a plurality of requirement values ​​of PRPL (Pose to Render to Photon Latency) or RPL (Render to Photon Latency) according to the application as the delay request information.

5. The information processing device of claim 1, wherein the acquisition unit acquires information on a maximum data burst amount of a downlink QoS flow assigned to a session established for the application, and the decision unit makes a decision regarding the generation of data related to the video content to be transmitted to the terminal device based on the delay request information, the tolerance information, and the maximum data burst amount information.

6. The information processing device of claim 1, further comprising a division unit that divides a first image of the video content into a plurality of second images having a smaller number of pixels than the first image, and the determination unit assigns a communication priority to each of the plurality of second images.

7. An information processing device as described in claim 6, further comprising a setting unit that sets multiple PDU (Protocol Data Unit) sets to which different communication priorities are assigned, wherein the determination unit assigns the second images to the PDU sets based on a priority assigned to each of the multiple second images and a priority assigned to each of the multiple PDU sets.

8. The information processing device of claim 1, wherein the determination unit determines an area of ​​an image related to the video content to be transmitted to the terminal device based on the tolerance information, and makes a decision regarding the generation of data related to the video content to be transmitted to the terminal device based on the delay request information, the tolerance information, and the area information.

9. The information processing device of claim 8, wherein the acquisition unit acquires information on a maximum data burst amount of a downlink QoS flow assigned to a session established for the application, and the decision unit makes a decision regarding the generation of data related to the video content to be transmitted to the terminal device based on the delay request information, the tolerance information, the area information, and the maximum data burst amount information.

10. The information processing device according to claim 8, wherein the acquisition unit acquires sensor information from a sensor equipped in the terminal device, and the determination unit determines the area of ​​the image based on the sensor information and the tolerance information.

11. The information processing device according to claim 10, further comprising a generation unit that generates an AI (Artificial Intelligence) or ML (Machine Learning) model using the sensor information detected at multiple different times, wherein the determination unit determines the area of ​​the image based on information obtained by inputting the sensor information into the AI ​​or ML model.

12. An information processing device as described in claim 1, further comprising a detection unit that detects the magnitude or speed of change in the video contained in the video content, wherein the identification unit identifies information about the delay request based on the magnitude or speed of the change in the video, and the decision unit makes a decision regarding the generation of data related to the video content based on the information about the delay request and the tolerance information.

13. The information processing device according to claim 12, wherein the determination unit makes a determination regarding a transmission frequency of I frames of a GOP (Group of Picture) of the video content according to a magnitude or speed of change in the video.

14. The information processing device according to claim 12, wherein the determination unit makes a determination regarding a frame rate of data related to the video content depending on a magnitude or speed of change in the video.

15. An information processing device as described in claim 12, further comprising a request unit that requests the terminal device to increase or decrease the frequency of transmitting sensor information from a sensor provided in the terminal device to the information processing device when the delay request information satisfies a predetermined criterion.

16. The information processing device according to claim 15, wherein the request unit, in conjunction with requesting the terminal device to increase or decrease the transmission frequency of the sensor information, requests other network devices to set or update a Configured Grant (CG) having a period corresponding to the transmission frequency.

17. An information processing device as described in claim 1, further comprising a notification unit which notifies the terminal device of periodic information regarding sensor information used in processing for reflecting user actions in the video content, wherein the determination unit: determines a first period, which is a period in which the terminal device detects sensor information, based on information about a frame period in which the video content is displayed; determines a second period, which is a period in which the terminal device transmits the sensor information, based on information about the delay request; and determines a third period, which is a period in which data related to the video content is transmitted to the terminal device, based on information about the delay request; and the notification unit notifies the terminal device of information regarding the first period, information regarding the second period, and information regarding the third period as the periodic information.

18. The information processing device according to claim 17, further comprising: a request unit that requests another network device to set at least one of the second-cycle discontinuous transmission and the third-cycle discontinuous reception in the terminal device.

19. An information processing device as described in claim 1, further comprising: a request unit that requests another network device to set up QoS monitoring; wherein the acquisition unit acquires a first packet delay measurement result of an uplink QoS flow assigned to a session established for the application and a second packet delay measurement result of a downlink QoS flow assigned to a session established for the application; and wherein the decision unit executes one of the following processes: a first process of making a decision regarding the generation of data related to the video content to be sent to the terminal device based on the delay request information and the tolerance information; and a second process of making a decision regarding the generation of data related to the video content to be sent to the terminal device based on the delay request information and at least one of the first packet delay measurement result and the second packet delay measurement result.

20. An information processing method comprising: identifying information on a delay request regarding the reflection of a user's actions in XR (Extended Reality) video content; acquiring tolerance information regarding the transmission delay of a Quality of Service (QoS) flow assigned to a session established for an application related to the video content; and making a decision regarding the generation of data related to the video content to be transmitted to a terminal device used by the user based on the delay request information and the tolerance information.

Images