Terminal device, information processing device, and communication method

Abstract

A terminal device according to the present disclosure is provided with a control unit. The control unit notifies an information processing device of information including requirement information related to one or more communication requirements before starting communication. The control unit selects a communication requirement. The control unit communicates with a base station to which the selected communication requirement is allocated among one or more base stations allocated for each of the one or more communication requirements. When it is determined that the selected communication requirement cannot be satisfied in communication with the base station, the control unit performs handover from the base station to another base station that satisfies the selected communication requirement.

Description

Terminal device, information processing device, and communication method

[0001] The present disclosure relates to a terminal device, an information processing device, and a communication method.

[0002] Recent mobile networks (e.g., cellular networks such as 5G) are required to have high communication performance (e.g., low latency, high reliability, and / or high throughput). For example, mobile networks are required to perform communication that satisfies the high communication performance required by terminal devices.

[0003] In a mobile network, handover occurs when a terminal device moves, for example, and there are known techniques for satisfying communication performance before and after the handover.

[0004] International Publication No. 2022 / 180849 Japanese Patent Application Laid-Open No. 2014-171128 International Publication No. 2023 / 157077 International Publication No. 2022 / 249273

[0005] In recent years, a technology has become known in which a single terminal device performs one or more communications via one or more base stations. When a single terminal device performs one or more communications in this manner, different communication performances may be required for each communication.

[0006] In this way, a terminal device that communicates with one or more base stations is required to perform communication that satisfies the communication requirements of the terminal device in each communication.

[0007] Therefore, the present disclosure proposes a terminal device, an information processing device, and a communication method that are capable of performing communication that satisfies communication requirements in each communication with one or more base stations.

[0008] 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.

[0009] A terminal device of the present disclosure includes a control unit. Before starting communication, the control unit notifies an information processing device of information including requirement information regarding one or more communication requirements. The control unit selects the communication requirements. The control unit communicates with a base station to which the selected communication requirements are assigned, from one or more base stations assigned for each of the one or more communication requirements. If the control unit determines that the selected communication requirements cannot be satisfied in the communication with the base station, it performs handover from the base station to another base station that satisfies the selected communication requirements.

[0010] 1 is a diagram illustrating an overview of communication processing related to a proposed technique of the present disclosure. FIG. 1 is a diagram illustrating an overview of communication processing related to a proposed technique of the present disclosure. FIG. 2 is a block diagram illustrating an example overall configuration of a communication system according to an embodiment of the present disclosure. FIG. 3 is a block diagram illustrating an example configuration of a terminal device according to an embodiment of the present disclosure. FIG. 4 is a diagram illustrating an example configuration of a server device according to an embodiment of the present disclosure. FIG. 5 is a diagram illustrating an example configuration of a base station according to an embodiment of the present disclosure. FIG. 6 is a diagram illustrating an example configuration of a 5G Core according to an embodiment of the present disclosure. FIG. 7 is a diagram illustrating an overview of communication processing in an allocation phase according to an embodiment of the present disclosure. FIG. 8 is a diagram illustrating details of communication processing in an allocation phase according to an embodiment of the present disclosure. FIG. 9 is a sequence diagram illustrating an example flow of a process for acquiring RU location information according to an embodiment of the present disclosure. FIG. 10 is a sequence diagram illustrating an example flow of communication processing in the allocation phase according to an embodiment of the present disclosure. FIG. 11 is a diagram illustrating an example calculation process for calculating a control policy according to an embodiment of the present disclosure. FIG. 12 is a diagram illustrating an example calculation process for calculating a control policy according to an embodiment of the present disclosure. FIG. 13 is a sequence diagram illustrating an example flow of a process for notifying RAN parameters according to an embodiment of the present disclosure. FIG. 14 is a sequence diagram illustrating an example flow of a communication start process according to an embodiment of the present disclosure. FIG. 15 is a diagram illustrating an overview of handover processing according to an embodiment of the present disclosure. FIG. 16 is a diagram illustrating an overview of handover processing according to an embodiment of the present disclosure. FIG. 17 is a sequence diagram illustrating an example flow of handover processing according to an embodiment of the present disclosure. FIG. 1 is a sequence diagram showing an example of a flow of handover according to an embodiment of the present disclosure. FIG. 2 is a diagram showing another example of a flow of handover according to an embodiment of the present disclosure. FIG. 3 is a diagram showing another example of a flow of handover according to an embodiment of the present disclosure. FIG. 4 is a diagram showing another example of a flow of handover according to an embodiment of the present disclosure. FIG. 5 is a diagram showing another example of a flow of handover according to an embodiment of the present disclosure. FIG. 6 is a diagram showing an overview of a process for changing a communication requirement according to an embodiment of the present disclosure. FIG. 7 is a sequence diagram showing an example of a flow of a process for changing a communication requirement according to an embodiment of the present disclosure.FIG. 1 is a diagram illustrating another example of communication processing in an allocation phase according to an embodiment of the present disclosure. FIG. 2 is a diagram illustrating another example of communication processing in a communication phase according to an embodiment of the present disclosure. FIG. 3 is a diagram illustrating another example of communication processing in a communication phase according to an embodiment of the present disclosure. FIG. 4 is a diagram illustrating an example of a method for determining a pair according to an embodiment of the present disclosure. FIG. 5 is a diagram illustrating an example of a method for determining a pair according to an embodiment of the present disclosure. FIG. 6 is a diagram illustrating an example of a method for determining a pair according to an embodiment of the present disclosure. FIG. 7 is a diagram illustrating an example of a method for determining a pair according to an embodiment of the present disclosure. FIG. 8 is a diagram illustrating an example of a travel route proposed by a server device according to another embodiment of the present disclosure. FIG. 9 is a diagram illustrating an example of a communication system according to another embodiment of the present disclosure. FIG. 10 is a diagram illustrating an example of communication switching according to another embodiment of the present disclosure. FIG. 11 is a diagram illustrating another example of a communication system according to another embodiment of the present disclosure.

[0011] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In this specification and drawings, components having substantially the same functional configurations are designated by the same reference numerals, and redundant description will be omitted.

[0012] In this specification and drawings, similar components of the embodiments may be distinguished by adding at least one different alphabet and / or number after the same reference numeral. However, if there is no need to particularly distinguish between the similar components, only the same reference numeral will be used.

[0013] One or more embodiments (including examples, modifications, and application examples) 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 each other. Therefore, these embodiments may contribute to solving different purposes or problems and may produce different effects from each other.

[0014] <<1. Introduction>> <1-1. Problem> For example, in recent years, a technique has been known in which a single terminal device performs one or more communications. For example, the terminal device includes one or more communication modules and performs one or more communications using each communication module.

[0015] In this case, the terminal device may perform communication by setting different communication requirements for each of one or more communications. For example, an ambulance, a doctor's car, a doctor helicopter (doctor helicopter), etc. (hereinafter collectively referred to as an emergency vehicle) are equipped with various devices such as a camera for photographing a patient (for example, a 4K camera) and an ultrasound diagnostic device.

[0016] These devices can be connected to hospitals, etc. via communication devices (terminal devices). For example, images captured by the cameras are transmitted to hospitals via the terminal devices and used for diagnosis, treatment, etc.

[0017] For example, a terminal device may establish communication for each device to which it is connected. The device and the terminal device may be connected using, for example, tethering. It is desirable for the terminal device to communicate in a manner that satisfies communication performance (e.g., high speed, low latency, and / or high reliability) appropriate for the device.

[0018] For example, the communication performance (hereinafter also referred to as communication requirements) required for each device may differ. Furthermore, communication between devices mounted on emergency vehicles and used for diagnosis, treatment, etc. may generally require higher performance than communication for entertainment, etc.

[0019] Furthermore, communication between these devices is required to be more stable and uninterrupted. That is, terminal devices are required to be able to simultaneously communicate with multiple different communication requirements in a stable manner (for example, without interruption).

[0020] Thus, there is a need for a mechanism that can stably guarantee different high-level communication requirements, such as high speed, low latency, and / or high reliability.

[0021] The terminal device is not limited to an emergency vehicle, and may be a smartphone, a tablet terminal, a PC, a machine-to-machine (M2M) device, or an Internet of Things (IoT) device, as long as the terminal device performs communication by setting different communication requirements for each of one or more communications.

[0022] <1-2. Overview of Proposed Technology> An overview of communication processing according to the proposed technology of the present disclosure will be described using Figures 1 and 2. Figures 1 and 2 are diagrams illustrating an overview of communication processing according to the proposed technology of the present disclosure. The communication processing according to the proposed technology is executed in a communication system.

[0023] As shown in Figures 1 and 2, a communication system according to the proposed technique of the present disclosure includes a terminal device 100, a server device 200, and one or more base stations 300 (base stations 300_1 to 300_3 in Figures 1 and 2). Note that the number of terminal devices 100 and the number of base stations 300 are merely examples. There may be two or more terminal devices 100. There may also be two or less base stations 300, or four or more base stations 300.

[0024] 1, the terminal device 100 first notifies the server device 200 of requirement information (e.g., notification information) related to one or more communication requirements (step S1). Here, the terminal device 100 notifies the server device 200 of requirement information related to two communication requirements (first and second communication requirements).

[0025] The server device 200 assigns a base station 300 for each of one or more communication requirements according to the requirement information. For example, the server device 200 assigns the communication requirements to the base station 300 by specifying the communication requirements and reserving the base station 300. In response to a request from the server device 200, network parameters (e.g., RAN parameters) according to the communication requirements are set in the base station 300, thereby assigning the communication requirements to the base station 300.

[0026] 1, the server device 200 assigns a first communication requirement (e.g., high-capacity communication) to the base station 300_1. For example, the server device 200 notifies the base station 300_1 of first assignment information regarding the first communication requirement (step S2).

[0027] 1, the server device 200 assigns a second communication requirement (e.g., low-latency communication) to the base station 300_2. For example, the server device 200 notifies the base station 300_2 of first assignment information regarding the second communication requirement (step S3).

[0028] For example, the terminal device 100 selects at least one of one or more communication requirements and performs communication. The terminal device 100 selects the communication requirement depending on the application to be executed. Alternatively, the terminal device 100 selects the communication requirement depending on a device (or a request from the device) connected by tethering or the like. Here, it is assumed that the terminal device 100 selects both the first and second communication requirements.

[0029] The terminal device 100 communicates with the base station 300 to which the selected communication requirement is assigned. In the example of Fig. 1, the terminal device 100 communicates with the base station 300_1 to which the first communication requirement is assigned, satisfying the first communication requirement, and communicates with the base station 300_2 to which the second communication requirement is assigned, satisfying the second communication requirement (step S4).

[0030] Here, for example, it is assumed that it is determined that the second communication requirement cannot be satisfied in communication with the base station 300_2. This determination may be made by, for example, the terminal device 100 or the base station 300_2. Here, it is assumed that the determination is made by the base station 300_2.

[0031] For example, the base station 300_2 determines that the second communication requirement cannot be satisfied based on the communication quality or the location of the terminal device 100.

[0032] The base station 300_2 does not have to determine that the second communication requirement cannot be satisfied only if the second communication requirement is actually no longer satisfied. Even if the second communication requirement is currently satisfied, the base station 300_2 may determine that the second communication requirement cannot be satisfied if, for example, there is a possibility that the second communication requirement will not be satisfied in the future.

[0033] For example, the base station 300_2 determines whether the second communication requirement can be satisfied, depending on the movement route and current location of the terminal device 100. Alternatively, the base station 300_2 may determine whether the second communication requirement can be satisfied, depending on a change in actual communication quality.

[0034] If it is determined that the second communication requirement is not satisfied, the base station 300_2 performs handover to another base station 300 (the base station 300_3 in FIG. 2) (step S5).

[0035] The base station 300_3 that performs the handover may be a base station 300 to which the second communication requirement has been assigned in advance, or may be a spare base station 300 to which no specific communication requirement has been assigned. When performing handover to the spare base station 300_3, for example, the base station 300_2 may notify the base station 300_3 to set communication parameters that satisfy the second communication requirement.

[0036] The terminal device 100 that has performed handover between the base station 300_2 and the base station 300_3 performs communication with the base station 300_3 that satisfies the second communication requirement (step S6).

[0037] In this way, in the communication system according to the proposed technique of the present disclosure, a base station 300 is assigned for each of one or more communication requirements. The terminal device 100 communicates with the base station 300 in accordance with the communication requirements. Furthermore, if it is determined that the desired communication requirements cannot be satisfied in communication with the base station 300, the terminal device 100 performs handover to another base station 300 that satisfies the communication requirements.

[0038] As a result, the communication system according to the proposed technique of the present disclosure can perform communication that satisfies communication requirements in each communication with one or more base stations 300. More specifically, the communication system can stably guarantee different communication requirements for each of one or more communications.

[0039] <<2. Configuration Example of Communication System>> <2-1. Overall Configuration Example of Communication System> Fig. 3 is a block diagram showing an overall configuration example of a communication system according to an embodiment of the present disclosure. The communication system shown in Fig. 3 includes a terminal device 100, a server device 200, a base station (Radio Access Network: RAN) 300, a 5G Core 400, an application function (AF) 500, and a DN (Data Network) 600.

[0040] (Terminal Device 100) The terminal device 100 is a communication device that performs wireless communication with the base station 300 under the control of the base station 300. The terminal device 100 may also be referred to as UE (User Equipment). Hereinafter, the terminal device 100 may be referred to as UE100.

[0041] The terminal device 100 is a wireless communication device that wirelessly communicates with other communication devices such as a base station 300. The terminal device 100 may be, for example, a mobile phone, a smart device (smartphone or tablet), a personal digital assistant (PDA), or a personal computer. The terminal device 100 may also be a device such as a commercial camera equipped with a communication function, or a motorcycle, mobile broadcast vehicle, emergency vehicle, or the like equipped with a communication device such as a field pickup unit (FPU). The terminal device 100 may also be an industrial robot equipped with a communication function. The terminal device 100 may also be a machine-to-machine (M2M) device or an Internet of Things (IoT) device. The terminal device 100 may also be a mobile object such as an automobile or a drone.

[0042] The terminal device 100 may be capable of NOMA communication with the base station 300. Furthermore, the terminal device 100 may use an automatic repeat technique such as HARQ when communicating with the base station 300. The terminal device 100 may be capable of sidelink communication with other terminal devices 100. The terminal device 100 may also use an automatic repeat technique such as HARQ when performing sidelink communication. The terminal device 100 may also be capable of NOMA communication in communication (sidelink) with other terminal devices 100. Furthermore, the terminal device 100 may be capable of LPWA communication with other communication devices (e.g., the base station 300 and other terminal devices 100). Furthermore, the wireless communication used by the terminal device 100 may be wireless communication using millimeter waves. Furthermore, the wireless communication (including sidelink communication) used by the terminal device 100 may be wireless communication using radio waves, or wireless communication using infrared or visible light (optical wireless).

[0043] The terminal device 100 may also be a mobile device. The mobile device is a wireless communication device that can move. In this case, the terminal device 100 may be a wireless communication device installed in the mobile device, or may be the mobile device itself. For example, the terminal device 100 may be a vehicle that moves on a road, such as an automobile, bus, truck, or motorcycle, a vehicle that moves on rails installed on a track, such as a train, or a wireless communication device mounted on the vehicle. The mobile device may be a mobile terminal, or a mobile device that moves on land (ground in the narrow sense), underground, on water, or underwater. The mobile device may also be a mobile device that moves within the atmosphere, such as a drone or a helicopter, or a mobile device that moves outside the atmosphere, such as an artificial satellite.

[0044] The terminal device 100 may simultaneously connect to multiple base stations or multiple cells to perform communication. For example, when one base station supports a communication area through multiple cells (e.g., pCell, sCell), the multiple cells can be bundled together using carrier aggregation (CA) technology, dual connectivity (DC) technology, or multi-connectivity (MC) technology to enable communication between the base station 300 and the terminal device 100. Alternatively, the terminal device 100 can also communicate with the multiple base stations 300 via cells of different base stations 300 using coordinated multi-point transmission and reception (CoMP) technology.

[0045] The terminal device 100 according to an embodiment of the present disclosure can simultaneously perform communications with, for example, one or more base stations 300, each of which has different communication requirements.

[0046] (Server device 200) The server device 200 is an information processing device that communicates with the terminal device 100 via a cellular network, the Internet, or the like. In Fig. 3, the server device 200 is a device different from the 5G Core 400, but the server device 200 may be implemented as part of the 5G Core 400. Alternatively, the server device 200 may be implemented as part of the RAN 300 (base station 300).

[0047] The server device 200 may be realized as, for example, a cloud server or an edge server.

[0048] (Base Station 300) The base station 300 (RAN 300 in FIG. 3) is a communication device that operates a cell and provides wireless communication services to one or more terminal devices 100 located within the coverage of the cell. The cell is operated according to any wireless communication method, such as LTE or NR. The base station 300 is connected to a core network (5G Core 400 in FIG. 3). The base station 300 operates beams that can be identified by SSB (Synchronization Signal / PBCH Block), and can transmit and receive data to and from one or more terminal devices 100 via one or more beams.

[0049] Note that the base station 300 may be configured as a collection of multiple physical or logical devices. For example, in this embodiment, the base station 300 may be divided into multiple devices, a baseband unit (BBU) and an RU, and interpreted as a collection of these multiple devices. Additionally or alternatively, in this embodiment, the base station 300 may be either or both of a BBU and an RU. The BBU and the RU may be connected via a predetermined interface (e.g., eCPRI). Additionally or alternatively, the RU may be referred to as a remote radio unit (RRU) or a radio DoT (RD). Additionally or alternatively, the RU may correspond to a gNB-DU (gNB-DU) described later. Additionally or alternatively, the BBU may correspond to a gNB-CU (gNB-CU) described later. Alternatively, the RU may be connected to a gNB-DU (gNB-DU) described later. Furthermore, the BBU may correspond to a combination of a gNB-CU and a gNB-DU (gNB-DU) described later. Additionally or alternatively, the RU may be a device integrally formed with an antenna. The antennas of the base station 300 (e.g., antennas integrally formed with the RUs) may employ an Advanced Antenna System and support MIMO (e.g., FD-MIMO) and beamforming. In the Advanced Antenna System, the antennas of the base station 300 (e.g., antennas integrally formed with the RUs) may include, for example, 64 transmitting antenna ports and 64 receiving antenna ports.

[0050] Furthermore, multiple base stations 300 may be connected to each other. One or more base stations 300 may be included in a Radio Access Network (RAN). That is, the base station 300 may simply be referred to as a RAN, a RAN node, an Access Network (AN), or an AN node. The RAN in LTE is called an Enhanced Universal Terrestrial RAN (EUTRAN). The RAN in NR is called an NGRAN. The RAN in W-CDMA (UMTS) is called a UTRAN. The base station 300 in LTE is called an Evolved Node B (eNodeB) or eNB. That is, the EUTRAN includes one or more eNodeBs (eNBs). The base station 300 in NR is called a gNodeB or gNB. That is, the NGRAN includes one or more gNBs. Furthermore, the EUTRAN may include a gNB (en-gNB) connected to a core network (EPC) in an LTE communication system (EPS). Similarly, the NGRAN may include an ng-eNB connected to a core network (5GC) in a 5G communication system (5GS). Additionally or alternatively, if the base station 300 is an eNB, gNB, or the like, it may be referred to as a 3GPP access. Additionally or alternatively, if the base station 300 is a wireless access point (e.g., a Wi-Fi (registered trademark) access point), it may be referred to as a non-3GPP access. Additionally or alternatively, the base station 300 may be an optical extension device called an RRH (Remote Radio Head). Additionally or alternatively, if the base station 300 is a gNB, it may be referred to as a combination of the gNB CU (Central Unit) and gNB DU (Distributed Unit) described above, or as either one of them. The gNB CU hosts multiple upper layers (e.g., RRC, SDAP, PDCP) in the Access Stratum for communication with the UE, while the gNB-DU hosts multiple lower layers (e.g., RLC, MAC, PHY) in the Access Stratum.That is, among the messages and information described below, RRC signaling (e.g., various SIBs including MIB and SIB1, RRC Setup message, RRC Reconfiguration message) may be generated by the gNB CU, while DCI and various physical channels (e.g., PDCCH and PBCH) described below may be generated by the gNB-DU. Alternatively, among the RRC signaling, some configuration (setting information), such as IE:cellGroupConfig, may be generated by the gNB-DU, and the remaining configuration may be generated by the gNB-CU. These configurations (setting information) may be transmitted and received via the F1 interface described below. The base station 300 may be configured to be able to communicate with other base stations 300. For example, when multiple base stations 300 are eNBs or a combination of an eNB and an en-gNB, the base stations 300 may be connected to each other via the X2 interface. Additionally or alternatively, when multiple base stations 300 are gNBs or a combination of gn-eNBs and gNBs, the devices may be connected via an Xn interface. Additionally or alternatively, when multiple base stations 300 are a combination of gNB CUs and gNB DUs, the devices may be connected via the above-mentioned F1 interface. Messages and information (RRC signaling or DCI information, physical channel) described below may be communicated between multiple base stations 300 (e.g., via the X2, Xn, or F1 interfaces).

[0051] Furthermore, as described above, the base station 300 may be configured to manage multiple cells. A cell provided by the base station 300 is called a serving cell. The serving cell includes a PCell (Primary Cell) and an SCell (Secondary Cell). When dual connectivity (e.g., EUTRA-EUTRA Dual Connectivity, EUTRA-NR Dual Connectivity (ENDC), EUTRA-NR Dual Connectivity with 5GC, NR-EUTRA Dual Connectivity (NEDC), NR-NR Dual Connectivity) is provided to a UE (e.g., the terminal device 100), the PCell and zero or one or more SCell(s) provided by a Master Node (MN) are called a Master Cell Group. Furthermore, the serving cell may include a PSCell (Primary Secondary Cell or Primary SCG Cell). That is, when dual connectivity is provided to a UE, the PSCell and zero or one or more SCell(s) provided by a Secondary Node (SN) are called a Secondary Cell Group (SCG). Unless special configuration (e.g., PUCCH on SCell) is performed, the physical uplink control channel (PUCCH) is transmitted on the PCell and PSCell, but not on the SCell. Furthermore, radio link failure is detected on the PCell and PSCell, but not on the SCell (it does not need to be detected). Since the PCell and PSCell thus play special roles among the serving cell(s), they are also called special cells (SpCells). One cell may be associated with one downlink component carrier and one uplink component carrier. Furthermore, the system bandwidth corresponding to one cell may be divided into multiple bandwidth parts.In this case, one or more Bandwidth Parts (BWPs) may be configured in the UE, and one Bandwidth Part may be used by the UE as an Active BWP. Also, radio resources (e.g., frequency band, numerology (subcarrier spacing), slot format (Slot configuration)) that the terminal device 100 can use may differ for each cell, each component carrier, or each BWP.

[0052] (5G Core 400) The 5G Core 400 is an information processing device that functions as a core network. In FIG. 3, the 5G Core 400, which is a core network of NR or 5GS (5G system), is shown as an example of the core network, but the core network of the communication system according to this embodiment is not limited to the core network of NR or 5GS (5G system).

[0053] The communication system according to this embodiment may include a core network of 6G or LTE, which is the next generation cellular communication technology after NR and 5GS (5G system), instead of or in addition to the 5G Core 400.

[0054] 3, the server device 200 is connected to the 5G Core 400 via the AF 500, but the server device 200 may be connected to the 5G Core 400 without the AF 500. Alternatively, the 5G Core 400 may have the function of the AF 500.

[0055] The DN 600 also has a function that enables connection to MNO (Mobile Network Operator) proprietary services, the Internet, and third-party services.

[0056] In FIG. 3, the number of terminal devices (UE) 100, base stations (RAN) 300, 5G Core 400, AFs 500, and DNs 600 is one, but the number of these is not limited to one.

[0057] There may be two or more terminal devices 100. Also, there may be two or more 5G Cores 400. For example, an AF 500 and a DN 600 corresponding to each of the multiple 5G Cores 400 may be provided. Also, two or more base stations 300 may be connected to one 5G Core 400.

[0058] 4 is a block diagram showing an example of the configuration of the terminal device 100 according to an embodiment of the present disclosure. The terminal device 100 shown in FIG. 4 includes at least one communication unit 110, a tethering unit 120, an application execution unit 130, a storage unit 140, and a control unit 150.

[0059] Note that the configuration shown in the figure is a functional configuration, and the hardware configuration may be different. Furthermore, the functions of the terminal device 100 may be statically or dynamically distributed and implemented in multiple physically separated configurations. For example, the terminal device 100 may be composed of multiple devices.

[0060] (Communication Unit 110) The communication unit 110 is a signal processing unit for wireless communication with other wireless communication devices (for example, the base station 300 or other terminal devices 100). In the example of Fig. 4, the terminal device 100 includes a plurality of communication units 110 (communication units 110_1, 110_2, ...). The communication units 110_1, 110_2, ... may have the same configuration.

[0061] The communication unit 110 may be referred to as a wireless transceiver or simply as a transceiver. In this case, the communication unit 110 may be a transceiver conforming to the standard defined by the Technical Specification (TS) of 3GPP (registered trademark) (hereinafter referred to as a 3GPP transceiver).

[0062] The 3GPP transceiver may be a 3G transceiver, a 4G (LTE) transceiver, a 5G (NR) transceiver, or a transceiver of a generation after 5G.

[0063] The communication unit 110 is controlled by, for example, the control unit 150. The communication unit 110 supports one or more radio access methods. The communication unit 110 may support at least one of NR, LTE, B5G (Beyond 5G), and 6G. The communication unit 110 may support W-CDMA, cdma2000, and the like in addition to NR, LTE, B5G, and 6G.

[0064] The communication unit 110 may support an automatic retransmission technique such as HARQ (Hybrid Automatic Repeat reQuest). The communication unit 110 performs wireless communication under the control of the control unit 150. Some or all of the processing performed by the communication unit 110 may be performed by the control unit 150.

[0065] (Tethering Unit 120) The tethering unit 120 is a signal processing unit for connecting the terminal device 100 to devices in the vicinity of the terminal device 100. The tethering unit 120 connects to the devices in the vicinity using, for example, Bluetooth (registered trademark) or Wi-Fi (registered trademark). The connection between the terminal device 100 and the devices in the vicinity may be wireless or wired.

[0066] The tethering unit 120 executes the tethering function under the control of the control unit 150. A part or all of the processing executed by the tethering unit 120 may be executed by the control unit 150.

[0067] (Application Execution Unit 130) The application execution unit 130 provides an application service to the user by operating as an application. The application execution unit 130 executes, for example, at least one application installed in the terminal device 100.

[0068] (Storage Unit 140) The storage unit 140 is realized by, for example, a semiconductor memory element such as a RAM (Random Access Memory), a ROM (Read Only Memory), a flash memory, etc. The storage unit 140 stores, for example, applications and programs executed by the application execution unit 130, etc.

[0069] (Control Unit 150) The control unit 150 is a controller that controls each unit of the terminal device 100. The control unit 150 is realized by a processor such as a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or a GPU (Graphics Processing Unit).

[0070] For example, the control unit 150 is realized by a processor executing various programs stored in a storage device inside the terminal device 100 using a RAM (Random Access Memory) or the like as a working area.

[0071] The control unit 150 may be realized by an integrated circuit such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA). A CPU, an MPU, an ASIC, and an FPGA can all be considered as controllers.

[0072] Furthermore, the control unit 150 may function as the application execution unit 130 .

[0073] 5 is a diagram illustrating a configuration example of the server device 200 according to an embodiment of the present disclosure. The server device 200 includes a communication unit 210, a storage unit 220, and a control unit 230. Note that the configuration illustrated in FIG. 5 is a functional configuration, and the hardware configuration may be different.

[0074] Furthermore, the functions of the server device 200 may be statically or dynamically distributed across multiple physically separated components. For example, the server device 200 may be configured by multiple devices.

[0075] (Communication Unit 210) The communication unit 210 is a communication interface for communicating with other devices. The communication unit 210 may be a network interface or a device connection interface.

[0076] For example, the communication unit 210 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, a USB port, and the like.

[0077] The communication unit 210 may be a wired interface or a wireless interface. The communication unit 210 functions as a communication means of the server device 200. The communication unit 210 communicates with the terminal device 100 and the like under the control of the control unit 230.

[0078] (Storage Unit 220) The storage unit 220 is a data readable / writable storage device such as a DRAM, an SRAM, a flash memory, a hard disk, etc. The storage unit 220 functions as a storage unit of the server device 200.

[0079] The storage unit 220 includes an allocation database (DB) 221. The allocation DB 221 holds allocation information, which will be described later.

[0080] (Control Unit 230) The control unit 230 is a controller that controls each unit of the server device 200. The control unit 230 is realized by a processor such as a CPU, an MPU, or a GPU.

[0081] For example, the control unit 230 is realized by a processor executing various programs stored in a storage device inside the server device 200 using RAM (Random Access Memory) or the like as a working area.

[0082] The control unit 230 may be realized by an integrated circuit such as an ASIC or an FPGA. A CPU, an MPU, a GPU, an ASIC, and an FPGA can all be considered as controllers.

[0083] 2-4. Configuration Example of Base Station> Fig. 6 is a diagram illustrating a configuration example of a base station 300 according to an embodiment of the present disclosure. The base station 300 in Fig. 6 includes a Service Management and Orchestration (SMO) 310, a NearRT (Real-Time)-RIC (RAN Intelligent Controller) 320, at least one Central Unit (CU) 330, at least one Distributed Unit (DU) 340, and at least one Radio Unit (RU) 350. Note that the configuration illustrated in Fig. 6 is a functional configuration, and the hardware configuration may be different.

[0084] Furthermore, the functions of base station 300 may be statically or dynamically distributed across multiple physically separated components. For example, each component of base station 300 may be composed of multiple devices.

[0085] The base station 300 in Fig. 6 is configured in accordance with, for example, the O-RAN (Open Radio Access Network) specifications. In O-RAN, an RIC is defined as a control unit responsible for making RAN functions intelligent. The RIC includes two types of RICs with different control periods: a Non-Real Time RIC (for example, the Non-NearRT-RIC 311 in Fig. 6) and a NearRT-RIC 320.

[0086] (Non-NearRT-RIC 311) The Non-NearRT-RIC 311 is an RIC that is responsible for policy generation, notification, control, etc. related to the control of the RAN (base station 300). The Non-NearRT-RIC 311 operates at a longer cycle than the control cycle of the NearRT-RIC 320. The Non-NearRT-RIC 311 is placed inside the SMO 310 that performs maintenance and orchestration of the RAN.

[0087] (NearRT-RIC 320) NearRT-RIC 320 is a RIC that performs processing related to O-RAN network functions (e.g., at least one of O-CU-CP (O-RAN Central Unit Control Plane), O-CU-UP (O-RAN Central Unit User Plane), O-DU-CP (O-RAN Distributed Unit Control Plane), and O-RU (O-RAN Radio Unit)).

[0088] The NearRT-RIC 320 collects information from the network functions of the O-RAN and controls the network functions of the O-RAN according to the policy notified from the Non-NearRT-RIC 311 via the A1 interface.

[0089] The network function of the O-RAN is connected to the NG-Core via the NG interface. The NG-Core is, for example, a 5GC (5G Core 400 (see FIG. 3)).

[0090] The NearRT-RIC 320 includes a requirements DB 321. The requirements DB 321 holds requirement information related to communication requirements. The requirements DB 321 stores, for example, identification information of the terminal device 100, identification information that identifies the communication requirements, policy information corresponding to the communication requirements, identification information of the base station 300, and the base station 300 in association with each other as requirement information.

[0091] (SMO 310) The SMO 310 may control not only the NFs (Network Functions) such as the O-CU and O-DU, but also the Cloud. For example, the SMO 310 may be provided with an interface with an external network (O2 interface).

[0092] The SMO 310 may control the O-Cloud via the O2 interface. The O-Cloud is a virtualization infrastructure that provides virtual resources to the NF Deployment, which defines the virtual resources for vRAN applications.

[0093] The SMO 310 may also be connected to an O-RAN Radio Unit (O-RU) and perform management such as maintenance or monitoring of the O-RU. The SMO 310 may also operate in cooperation with other domains. For example, the SMO 310 may operate in cooperation with an AF.

[0094] The SMO 310 includes a BS (Base Station) database (DB) 312. The BS DB 312 holds, for example, BS information related to the base station 300. The BS DB 312 stores, for example, RU location information of the RU 350, BS identification information of the base station 300, and reservation information related to the usage reservation status, for example, in association with each other, as BS information.

[0095] (CU 330) The CU 330 is a processing unit that processes L2 / L3 functions of the Packet Data Convergence Protocol (PDCP) sublayer or higher. The CU 330 has a requirement DB 331. The requirement DB 331 can hold the same requirement information as the requirement DB 321 of the NearRT-RIC 320.

[0096] (DU 340) The DU 340 is a processing unit that processes L2 / L1 functions below the RLC (Radio Link Control) sublayer. The DU 340 has a requirement DB 341. The requirement DB 341 can hold the same requirement information as the requirement DB 321 of the NearRT-RIC 320.

[0097] (RU 350) The RU 350 is a processing unit that processes the LOW PHY sublayer and the radio unit (Radio) among the functions of the DU 340. In this case, the DU 340 processes, for example, the RLC, MAC (Medium Access Control), and HIGH PHY sublayers.

[0098] The functions of the RUs 350 may be distributed over a fronthaul compliant with, for example, evolved Common Public Radio Interface (eCPRI), or alternatively, the functions of the RUs 350 may be distributed over a fronthaul compliant with, for example, Radio over Ethernet (RoE) or User Datagram Protocol / IP (UDP).

[0099] Here, the base station 300 may configure at least some of the functions of the CU 330, DU 340, and / or RU 350 using virtualization or containers and implement them on a cloud server. Furthermore, the base station 300 may dynamically and reconfigure at least some of the functions of the CU 330, DU 340, and / or RU 350 using a Software Defined Network (SDN). The base station 300 may also change its configuration using techniques such as O-RAN E2SM RC and CCC. Furthermore, the functions of the RU 350 of the base station 300 may be changed (NETCONF) using the M-Plane of the O-RAN front wheel.

[0100] Here, in this embodiment, different base stations 300 means that at least the RUs 350 are different. For example, the RUs 350 of the base station 300 and the other base stations 300 are different, but the CUs 330 and / or DUs 340 may be the same or different. In other words, the functions of the CUs 330 and / or DUs 340 may be shared between the different base stations 300.

[0101] The CU 330, DU 340, and / or RU 350 are connected via, for example, an Xn interface. The SMO 310 and the NearRT-RIC 320, CU 330, DU 340, and / or RU 350 are connected via, for example, an O1 interface. The NearRT-RIC 320 and the CU 330 and / or DU 340 are connected via, for example, an E2 interface.

[0102] <2-Configuration Example of 5.5G Core> FIG. 7 is a diagram illustrating a configuration example of a 5G Core 400 according to an embodiment of the present disclosure.

[0103] The control plane function group of the 5G Core 400 includes an Access and Mobility Management Function (AMF) 420, a Network Exposure Function (NEF) 440, and a Session Management Function (SMF) 430. In this way, the control plane function group is configured by a plurality of Network Functions (NFs).

[0104] The AMF 420 performs mobility management. The AMF 420 is connected to the base station 300, the SMF 430, and the NEF 440. The SMF 430 performs session management. The SMF 430 is connected to the AMF 420, the NEF 440, and the UPF (User Plane Function) 410.

[0105] The NEF 440 has a function of providing network function capabilities and events to a third party, the AF 500, and an edge computing function. The NEF 440 is connected to the AF 500, the SMO 310 of the base station 300, the AMF 420, and the SMF 430.

[0106] The UPF 410 has a function of user plane processing. The UPF 410 functions as a forwarding processor for user plane data. The UPF 410 also functions as a gateway connected to the base station 300.

[0107] Here, the 5G Core 400 may configure each NF using virtualization or a container and implement it on a cloud server. The 5G Core 400 can dynamically and re-configure each NF using SDN.

[0108] <<3. Example of Communication Processing>> As described above, in the communication system of this embodiment, communication processing is executed. The communication processing is divided into an assignment phase in which communication requirements are assigned to a base station 300, and a communication phase in which the assigned base station 300 communicates with the terminal device 100. In the communication phase, handover processing is performed or processing to change the communication requirements is performed depending on whether the communication requirements are satisfied.

[0109] 8 is a diagram showing an overview of communication processing in the allocation phase according to an embodiment of the present disclosure. The communication processing in this allocation phase is executed, for example, before communication between the terminal device 100 and the base station 300 is started. For example, this communication processing may be executed when the terminal device 100 is started, or in accordance with an instruction from a user.

[0110] As shown in FIG. 8, the terminal device 100 notifies the server device 200 of notification information including one or more communication requirements (step S11).

[0111] For example, in accordance with an instruction from a user (not shown), the terminal device 100 notifies the server device 200 of notification information including communication requirements to be guaranteed during communication. The notification information includes, for example, at least one of information regarding the communication requirements, terminal identification information for identifying the terminal device 100, location information regarding the location and / or movement route where the terminal device 100 communicates, and carrier information regarding carriers that the terminal device 100 can use.

[0112] The server device 200 determines a set of base stations 300 to which the communication requirements are to be assigned based on the notification information (step S12). For example, the server device 200 requests the 5G Core 400 to determine a base station 300 to be assigned for each communication requirement (an example of assignment information). For example, the server device 200 determines which 5G Core 400 to request based on carrier information included in the notification information.

[0113] Upon receiving the request to determine the base station 300, the 5G Core 400 determines the base station 300 to which the communication requirements are to be allocated, according to the location information of the terminal device 100. Alternatively, the 5G Core 400 may determine the base station 300 to which the communication requirements are to be allocated, according to at least one of radio wave information from the base station 300 (for example, the communication quality between the base station 300 and the terminal device 100), the number of users present in the cell of the base station 300, and a prediction result of the future usage status of the terminal device 100.

[0114] For example, the 5G Core 400 searches for base stations 300 that exist near a planned point (position) where communication is to be performed by the terminal device 100. Based on the search result, the 5G Core 400 selects base stations 300 that are greater than the number of communication requirements, and generates the base stations 300.

[0115] The 5G Core 400 makes a reservation for the selected base station 300. Here, the 5G Core 400 can make a reservation for the base station 300 by, for example, instructing the selected base station 300 to perform communication with the terminal device 100 that satisfies the assigned communication requirements.

[0116] The 5G Core 400 sets, for example, network parameters of a RAN optimized for each communication requirement for the reserved base station 300. The 5G Core 400 can set the network parameters by using the RIC.

[0117] The server device 200 reserves a base station 300 for each communication requirement included in the notification information, and generates a set 10 of base stations 300 including one or more reserved base stations 300.

[0118] 8, the server device 200 generates a set 10 including four base stations 300, namely, base stations 300_B1 to 300_B3 and 300_C. Different communication requirements are assigned to the base stations 300_B1 to 300_B3. The base station 300_C is a spare base station 300 to which no specific communication requirements are assigned.

[0119] As will be described later, when the base stations 300_B1 to 300_B3 are unable to perform communication that satisfies the communication requirements, the spare base station 300_C performs communication that satisfies the communication requirements with the terminal device 100 instead.

[0120] The base station 300_A is a base station 300 to which communication requirements are not assigned and which is not a spare base station 300, in other words, a base station 300 not included in the set 10 of base stations 300.

[0121] (Details of Communication Processing) FIG. 9 is a diagram illustrating details of communication processing in the allocation phase according to an embodiment of the present disclosure.

[0122] The terminal device 100 notifies the server device 200 of the notification information (step S21). As described above, the notification information includes at least one of information on communication requirements, terminal identification information, location information, and carrier information.

[0123] (Communication Requirements) Information on communication requirements includes, for example, information on communication performance that the terminal device 100 is to satisfy (or ensure) during communication.

[0124] For example, as described above, the terminal device 100 is connected to devices for performing diagnosis and treatment and functions as a communication device for these devices. Examples of devices for performing diagnosis and treatment include a high-resolution (e.g., 4K or 8K) camera for capturing images of a patient, an arm for performing remote surgery, a vital sensor, and the like.

[0125] The terminal device 100 transmits, for example, information acquired by these devices (for example, captured images, sensing results, etc.) and receives control information for controlling these devices. The terminal device 100 is required to perform stable communication while ensuring communication requirements required for each device.

[0126] For example, when the terminal device 100 functions as a communication device for a high-resolution camera, it is necessary to ensure high-capacity communication in order to transmit high-resolution images. Furthermore, when the terminal device 100 functions as a communication device for an arm that performs remote surgery, it is necessary to ensure low-latency communication in order to control the arm with high precision. When the terminal device 100 functions as a communication device for a vital sensor, it is necessary to ensure highly reliable communication in order to periodically transmit the sensing results of the vital sensor.

[0127] Furthermore, for example, when a doctor performs remote surgery using an arm while checking images from a high-definition camera from a remote location, the terminal device 100 may be required to simultaneously transmit high-definition images and receive control information for the arm.

[0128] For example, when control of a real haptic medical robot, 8K image transfer, 4K video transmission, and telecommunication services are used simultaneously in an emergency vehicle, the UE 100 is required to have an UL throughput of 130 Mbps.

[0129] For example, when control of a real haptic medical robot, feedback video, and telecommunication services are used simultaneously in an emergency vehicle, the UE 100 is required to have a DL throughput of 60 Mbps.

[0130] For example, when a real haptic medical robot is controlled in an emergency vehicle, the UE 100 is required to have a delay of 40 msec or less.

[0131] In this way, there may be one or more communication requirements notified by the terminal device 100. Furthermore, there may be cases where a communication system is required to simultaneously satisfy one or more communication requirements.

[0132] In addition, desired communication requirements may change over time. For example, 8K image transmission may be performed when checking the patient's affected area in detail, but may not be performed at other times. Furthermore, real haptic medical robots are used when providing treatment inside emergency vehicles. Thus, it is necessary to simultaneously and stably satisfy one or more fluctuating communication requirements.

[0133] The terminal device 100 specifies the communication requirements to be guaranteed using information related to the communication requirements. The information related to the communication requirements includes, for example, quality information related to communication quality and / or slice information related to network slices. The information related to the communication requirements includes, for example, requirement identification information for identifying the communication requirements. Examples of the requirement identification information include at least one of 5QI (5G QoS Identifier), NSSAI, S-NSSAI, etc.

[0134] Alternatively, the information about requirements may be information about specific communication performance, such as information about any one of the bandwidth used for communication, the allowable delay time, the allowable jitter value, and the allowable packet loss rate.

[0135] (Terminal Identification Information) The terminal identification information is information for identifying the terminal device 100 that notifies the notification information. Examples of the terminal identification information include at least one of an IMSI (International Mobile Subscriber Identity), an IMEI (International Mobile Equipment Identity), a TMSI (Temporary Mobile Subscriber Identity), a GUTI (Globally Unique Temporary Identifier), an MSIDN (Mobile Station International Subscriber Directory Number), an IP address assigned to the terminal device 100, and the like.

[0136] (Location Information) The location information includes information about a point (location) where the terminal device 100 communicates. The location information may include information about one or more points, or may include information about the movement route of the terminal device 100.

[0137] The location information includes, for example, information about the latitude, longitude, and / or altitude of a location where the terminal device 100 communicates. Alternatively, the location information may include, for example, information that associates information about the latitude, longitude, and / or altitude of a location where the terminal device 100 communicates with a scheduled time of arrival at that location.

[0138] The location information may also include information about the latitude, longitude, and / or altitude of the starting point, intermediate point, and / or end point of the travel route. Alternatively, the location information may include information relating to the latitude, longitude, and / or altitude of the starting point, intermediate point, and / or end point of the travel route, and information associating the estimated time of arrival at the starting point, intermediate point, and / or end point. Note that an intermediate point of a travel route is a point on the route that is set between the starting point and the end point. An intermediate point of a travel route may also be an intersection, etc.

[0139] (Carrier Information) The carrier information includes information about a communication carrier that can be used by the terminal device 100. Examples of the carrier information include at least one of an IMSI, an MNC (Mobile Network Code), an MCC (Mobile Country Code), and character string information indicating the communication carrier.

[0140] As shown in FIG. 9, the server device 200 that has acquired the notification information determines to which 5G Core 400 a request should be sent for each communication requirement based on the notification information (step S22).

[0141] The server device 200 selects the 5G Core 400 to which the request is to be sent, for example, according to the carrier information included in the notification information.

[0142] The server device 200 transmits a request to the AF 500 connected to the selected 5G Core 400 (step S23). This request is made for each transmission request. Alternatively, as will be described later, if a spare base station 300 is included in the set of base stations 300, a request for selecting the spare base station 300 is transmitted.

[0143] The request may include at least one of information on the communication requirements to be guaranteed, terminal identification information, and location information (hereinafter also referred to as terminal location information) of the terminal device 100. The terminal location information may include information on the location where the terminal device 100 communicates and / or information on the movement route of the terminal device 100.

[0144] Furthermore, in the case of a request related to a spare base station 300, the request may include information related to communication requirements that can be guaranteed by the spare base station 300. For example, if there is a possibility that the spare base station 300 will perform communication that satisfies the first communication requirement or the second communication requirement on behalf of the base station 300 that is currently communicating with the terminal device 100, the request may include information related to the first communication requirement and the second communication requirement.

[0145] The AF 500 that has acquired the request transfers the request to the 5G Core 400 (step S24). Furthermore, the 5G Core 400 that has acquired the request transfers the request to the SMO 310 (step S25).

[0146] Based on the location information of the request, the Non-NearRT-RIC 311 of the SMO 310 selects a base station 300 (more specifically, a DU 340) that is located within a predetermined range from the point where the terminal device 100 communicates and can guarantee the communication requirements (step S26).

[0147] For example, the Non-NearRT-RIC 311 of the SMO 310 holds the reservation status of the base station 300 and selects a base station 300 that can be reserved in response to a request.

[0148] The Non-NearRT-RIC 311 that has selected the reservable base station 300 stores the BS information in the BS DB 312 (step S27).

[0149] The BS information includes, for example, information associating at least one of RU location information relating to the location of the base station 300 (specifically, the RU 350), BS identification information, and reservation information relating to the reservation status. The reservation information includes at least one of time information relating to the reservation time of the base station 300 and reservation identification information for identifying the reservation.

[0150] The time information may include, for example, a scheduled time at which communication between the base station 300 and the terminal device 100 will start (hereinafter also referred to as a scheduled start time) and / or a scheduled time at which communication will end (hereinafter also referred to as a scheduled end time). The scheduled start time and / or the scheduled end time may be set according to, for example, the scheduled time included in the location information.

[0151] Furthermore, if there is no reservable base station 300, the Non-NearRT-RIC 311 notifies the server device 200 via the 5G Core 400 and the AF 500 that reservation is not possible. In other words, if the number of reservable base stations 300 is smaller than the number of base stations 300 for which reservation is requested, the Non-NearRT-RIC 311 notifies the server device 200 that reservation is not possible. In this case, the Non-NearRT-RIC 311 may notify the server device 200 of the number of reservable base stations 300 (or the number of unreservable base stations 300).

[0152] The server device 200 may request reservation of a plurality of base stations 300, such as a set of base stations 300 including a plurality of base stations 300, as will be described later. In this case, the Non-NearRT-RIC 311 may not allow reservation if the number of reservable base stations 300 is less than the requested number of base stations 300.

[0153] Alternatively, the Non-NearRT-RIC 311 may reserve only the base stations 300 that can be reserved, and notify the server device 200 that there are base stations 300 that could not be reserved. In this case, the Non-NearRT-RIC 311 may notify the server device of information regarding the communication requests that were assigned to the base stations 300 that could be reserved (or that were not assigned to the base stations 300). The server device 200 may, for example, request another 5G Core 400 to reserve the base station 300 to which the communication request that could not be reserved should be assigned.

[0154] The Non-NearRT-RIC 311 of the SMO 310 that selected the reservable base station 300 notifies the NearRT-RIC 320 of reservation request information (step S28). The reservation request information includes, for example, policy information corresponding to the communication requirements to be allocated to the selected base station 300 and / or terminal identification information. The policy information is calculated, for example, by the SMO 310. Details of the policy information will be described later.

[0155] The NearRT-RIC 320, which has acquired the reservation request information, stores the reservation requirement information in the requirement DB 321 in accordance with the reservation request information (step S29). The reservation requirement information is, for example, information that associates terminal identification information, information related to communication requirements, policy information, BS identification information that identifies the base station 300, and at least a portion of BS information related to the base station 300. The information related to communication requirements may include, for example, requirement identification information that identifies the communication requirements.

[0156] This reservation requirement information can also be held in the requirement DB 331 of the CU 330 and the requirement DB 341 of the DU 340.

[0157] The NearRT-RIC 320, which has stored the reservation requirement information in the requirement DB 321, notifies the Non-NearRT-RIC 311 of the SMO 310 of a reservation completion notification (step S30). The reservation completion notification may include, for example, information that associates terminal identification information, information related to communication requirements, and base station identification information.

[0158] The SMO 310, which has acquired the reservation completion notification, notifies the 5G Core 400 of the registration completion notification (step S31).

[0159] The registration completion notice may include, for example, registration information in which terminal identification information, information on communication requirements, and BS identification information are associated with each other. The information on communication requirements may include, for example, requirement identification information that identifies the communication requirements.

[0160] The 5G Core 400, which has acquired the registration completion notification, transmits an allocation completion notification to the AF 500 (step S32). The allocation completion notification may include, for example, reservation success / failure information indicating whether the allocation (reservation) of the base station 300 was successful or not, and / or reservation identification information that identifies the reservation. The reservation success / failure information is, for example, Boolean information indicating whether the reservation was successful or not. Furthermore, the reservation identification information is integer or string information indicating a reservation ID.

[0161] The AF 500 transfers the acquired allocation completion notification to the server device 200 (step S33).

[0162] Here, the reservation according to this embodiment means, for example, allocating communication requirements to the base station 300 in advance.

[0163] For example, the server device 200 requests the base station 300 to perform communication that satisfies the communication requirements in communication with the terminal device 100. More specifically, the server device 200 requests the base station 300 to reserve a base station that can perform communication that satisfies the communication requirements in communication with the terminal device 100.

[0164] When a base station 300 capable of performing communication that satisfies the communication requirements is reserved, the server device 200 acquires reservation success / failure information indicating the success of the reservation. On the other hand, when a base station 300 capable of performing communication that satisfies the communication requirements is not reserved, the server device 200 acquires reservation success / failure information indicating the failure of the reservation.

[0165] Upon receiving the reservation success / failure information indicating that the reservation was successful, the server device 200 determines that the allocation of the communication requirements to the base station 300 was successful.

[0166] The server device 200, which has acquired the reservation success / failure information indicating that the reservation was successful, stores the allocation information in the allocation DB 221 (step S34). The allocation information is, for example, information in which reservation identification information and core identification information for identifying the 5G Core 400 are associated with each other.

[0167] The reservation identification information may be included in, for example, an allocation completion notification. The core identification information is, for example, information for identifying the 5G Core 400 corresponding to the base station 300 for which the reservation has been completed, and may include, for example, destination information of the 5G Core 400.

[0168] The server device 200, which has acquired the reservation success / failure information indicating that the reservation has failed, requests another 5G Core 400 to reserve the base station 300. For example, the processes of steps S23 to S33 are repeated until the reservations of the base stations 300 to which all communication requirements are assigned and the spare base stations 300 are completed.

[0169] When the allocation of communication requirements (or spares) to the base station 300 is completed, the server device 200 transmits an allocation completion notification to the terminal device 100 (step S35). This allocation completion notification may include allocation success / failure information indicating whether the allocation by the base station 300 was successful, and / or allocation identification information identifying the allocation. The allocation success / failure information is, for example, Boolean information indicating the success / failure of the allocation. The allocation identification information is integer or string information indicating an allocation ID. The allocation identification information may be, for example, the same as the reservation identification information.

[0170] It is assumed that even though the server device 200 has requested allocation (reservation) of the base station 300 from all 5G Cores 400 of the communication carrier available to the terminal device 100, none of the 5G Cores 400 has been able to reserve the base station 300. In this case, in step S35, the server device 200 notifies the terminal device 100 of an allocation completion notification including allocation success / failure information indicating allocation failure.

[0171] Here, an example of communication using the allocated base station 300 will be described. For example, it is assumed that communication that satisfies communication requirements is performed with the terminal device 100.

[0172] In this case, the NearRT-RIC 320 controls the network parameters based on the policy information stored in the requirement DB 321 (step S36). Also, the 5G Core 400 controls the gNBs 360_1 and 360_2 (step S37).

[0173] 9, gNB360_1, 360_2 are, for example, base stations 300 having the functions of CU330, DU340 and RU350. In other words, gNB360_1, 360_2 are base stations 300 excluding the functions of SMO310 and NearRT-RIC320.

[0174] 9, the gNB 360_1 performs data communication that ensures the communication requirements with the terminal device 100 (step S38). Note that the terminal device 100 may perform data communication with the gNB 360_2 that satisfies communication requirements different from those of the gNB 360_1.

[0175] In this way, the server device 200 reserves in advance the base station 300 that can perform communication that satisfies the communication requirements, in other words, it assigns the communication requirements in advance to the base station 300. This allows the terminal device 100 to simultaneously perform one or more communications that satisfy different communication requirements.

[0176] (Processing for Acquiring RU Location Information) As described above, prior to executing the communication process, the SMO 310 acquires the location information of the RU 350. Here, an example of the processing for acquiring the location information of the RU 350 will be described.

[0177] 10 is a sequence diagram illustrating an example of a flow of a process for acquiring RU location information according to an embodiment of the present disclosure. The acquisition process illustrated in FIG. 10 is executed in advance, for example, prior to the execution of a communication process.

[0178] First, the SMO 310 inquires of the RU 350 about RU location information relating to the location of the RU 350 (step S101). The RU 350 returns the RU location information to the SMO 310 (step S102).

[0179] The SMO 310 writes the acquired RU location information into the BS DB 311 (step S103).

[0180] For example, the SMO 310 queries all connected RUs 350 for RU location information.

[0181] (Communication Processing in Allocation Phase) FIG. 11 is a sequence diagram showing an example of the flow of communication processing in the allocation phase according to an embodiment of the present disclosure.

[0182] The terminal device 100 (hereinafter also referred to as the UE 100) transmits notification information to the server device 200 (hereinafter also referred to as the Server 200) (step S201).

[0183] The server 200 determines to which 5G core 400 the request should be sent (step S202). For example, the server 200 selects the 5G core 400 to notify of the request.

[0184] For example, the server 200 selects at least one 5G core 400 to issue a request. The server 200 sets the selected one or more 5G cores 400 as candidates for the 5G core 400 to issue a request.

[0185] Server 200 selects one of the candidate 5G Cores 400 as the 5G Core 400 that will issue the request.

[0186] The server 200 notifies the NEF 440 of the selected 5G core 400 of the request (step S203). The NEF 440 notifies the SMO 310 of the acquired request (step S204).

[0187] The SMO 310 selects a base station 300 that can be reserved, in other words, that can be assigned communication requirements, based on the RU location information acquired in advance and / or the reservation status of the base station 300 (more specifically, the DU 340) (step S205).

[0188] If there is no base station 300 to select, the SMO 310 executes step S216.

[0189] The SMO 310, having selected a reservable base station 300, writes BS information including information about the selected base station 300 into the BS DB 312 (step S206). The BS information includes, for example, information associating at least one of RU location information regarding the location of the base station 300 (specifically, the RU 350), BS identification information, and reservation information regarding the reservation status.

[0190] The SMO 310 calculates a control policy for RIC based on the communication requirements to be assigned to the base station 300 (step S207). The calculation process for calculating the control policy will be described later with reference to FIGS.

[0191] The SMO 310 notifies the NearRT-RIC 320 of reservation request information including policy information related to the calculated control policy (step S208). The SMO 310 notifies the NearRT-RIC 320 of the reservation request information via, for example, the Non-NearRT-RIC 311. The reservation request information includes, for example, policy information corresponding to communication requirements to be allocated to the selected base station 300 and / or terminal identification information.

[0192] The NearRT-RIC 320, which has acquired the reservation request information, writes reservation requirement information to the requirement DB 321 in accordance with the reservation request information (step S209). The reservation requirement information is, for example, information that associates at least a portion of terminal identification information, information related to communication requirements, policy information, BS identification information that identifies the base station 300, and BS information related to the base station 300.

[0193] The NearRT-RIC 320 notifies each CU 330 / DU 340 of the replication of the requirement DB 321 (step S210). For example, the NearRT-RIC 320 notifies all connected CUs 330 and DUs 340 of the replication of the requirement DB 321 by notifying them of reservation requirement information.

[0194] The CU330 / DU340 maintains a replication of the requirement DB321 (step S211). For example, the CU330 and DU340 maintain a replication of the requirement DB321 by writing reservation requirement information to the requirement DBs331 and 341. Note that when the NearRT-RIC320 generates RAN parameters from policy information, the CU330 / DU340 does not convert the RAN parameters from the policy information. In this case, steps S210 and S211 may be omitted.

[0195] In this way, the SMO 310 selects the base station 300 (more specifically, the DU 340) to which the communication requirements are to be allocated, thereby successfully reserving the base station 300.

[0196] When the reservation of the base station 300 is successful, the SMO 310 returns a registration completion notification to the 5G Core 400 (step S212). This registration completion notification includes, for example, terminal identification information, information on communication requirements, and registration information in which BS identification information is associated.

[0197] The 5G Core 400 returns a registration completion notification to the Server 200 (step S213).

[0198] The Server 200, which has acquired the registration completion notification, writes the allocation information to the allocation DB 221 (Step S214). The allocation information is, for example, information in which reservation identification information and core identification information for identifying the 5G Core 400 are associated with each other.

[0199] Server 200 returns an allocation completion notification to UE 100 (step S215).

[0200] Steps S212 to S215 are executed when the base station 300 can be reserved. As will be described later, steps S202 to S218 can be executed repeatedly (loop processing), but when steps S212 to S215 are executed, this loop ends (breaks). In other words, when step S218 is executed, the communication processing in the allocation phase ends.

[0201] On the other hand, if the SMO 310 is unable to select a base station 300 capable of performing communication that satisfies the communication requirements in step S205, step S216 is executed.

[0202] If the SMO 310 fails to select the base station 300 in step S205, the SMO 310 returns a reservation failure to the 5G Core 400 (step S216). The 5G Core 400 returns a reservation failure to the Server 200 (step S217).

[0203] Upon receiving the reply indicating the reservation failure, Server 200 deletes the destination (5G Core 400) for which the reservation failed from the candidates for 5G Core 400 to which the request is to be sent (step S218).

[0204] For example, in step S202, the server 200 selects at least one 5G core 400 to issue a request. The server 200 sets the selected one or more 5G cores 400 as candidates for the 5G core 400 to issue a request.

[0205] The server 200 deletes the 5G core 400 for which reservation failed from the candidate 5G cores 400.

[0206] If there is a 5G Core 400 to which a request has not yet been transmitted, the process returns to step S202, and a 5G Core 400 to which a request is to be transmitted is selected from the candidate 5G Cores 400.

[0207] On the other hand, if the request has been sent to all candidate 5G Cores 400, that is, if there are no candidate 5G Cores 400 to send a request to, Server 200 returns allocation information including allocation success / failure information indicating allocation failure to UE 100 (step S219).

[0208] Step S219 is executed when there is no candidate 5G Core 400 to issue a request. As described above, steps S202 to S218 can be repeatedly executed (loop processing), but when steps S212 to S219 are executed, this loop ends (breaks). In other words, when step S219 is executed, the communication processing in the allocation phase ends.

[0209] The processes from step S202 to step S219 are executed for each communication requirement. As a result, for each of one or more communication requirements, a base station 300 capable of performing communication that satisfies the communication requirement is reserved. In other words, a base station 300 is assigned for each communication requirement.

[0210] Furthermore, the processes from step S202 to step S219 may be executed to reserve a spare base station 300 to which no specific communication requirement is assigned. In this case, the SMO 310 selects, for example, one of the communication requirements requested by the terminal device 100 and selects a base station 300 that can perform communication.

[0211] As will be described later, when the base station 300 currently communicating with the terminal device 100 becomes unable to satisfy communication requirements due to a change in communication conditions or the like, the spare base station 300 communicates with the terminal device 100 in place of the base station 300. In this way, in response to a request from the Server 200, the SMO 310 can reserve a spare base station 300 that can take over communication of the reserved base station 300.

[0212] (Control Policy Calculation Process) Here, an example of a calculation process for calculating a control policy from communication requirements will be described with reference to Fig. 12 and Fig. 13. Fig. 12 and Fig. 13 are diagrams illustrating an example of a calculation process for calculating a control policy according to an embodiment of the present disclosure.

[0213] 12 , the 5G Core 400 notifies the SMO 310 of the communication requirements acquired from the server device 200 (step S41). For example, the 5G Core 400 notifies the SMO 310 of the communication requirements acquired from the server device 200.

[0214] The SMO 310 converts the acquired communication requirements into a control policy (step S42). For example, the SMO 310 calculates a control policy from the communication requirements based on a setting file related to the control policy. The setting file is a file that describes rules for converting the communication requirements into a specific control policy.

[0215] The Non-NearRT-RIC 311 in the SMO 310 notifies the NearRT-RIC 320 of the control policy information (policy information) (step S43).

[0216] The NearRT-RIC 320 derives RAN parameters to be set in the base station 300 from the acquired policy information (step S44). The NearRT-RIC 320 controls the parameters of the base station 300 based on the derived RAN parameters (step S45).

[0217] Note that the calculation process described here is an example, and the calculation process is not limited to the example in Fig. 12. For example, the conversion to the control policy may be performed by a component of the SMO 310. In this way, the entity that performs each step in the calculation process is not limited to the example in Fig. 12.

[0218] Next, an example of calculating a control policy from specific communication requirements will be described with reference to Fig. 13. The communication requirements and the like described here using specific numerical values ​​are merely examples, and the numerical values ​​and the like are not limited to these examples.

[0219] For example, assume that the 5G Core 400 notifies the SMO 310 of "guaranteed bandwidth of 90 Mbps on the uplink (UL)" as a communication requirement (step S46).

[0220] The SMO 310 converts the acquired communication requirements into a control policy using the control policy setting file (step S47).

[0221] The configuration file is a file that includes conversion rules for converting communication requirements into control policies. For example, the configuration file may include one or more conversion rules. For example, a conversion rule may include a combination of communication requirements and control policies.

[0222] For example, if the communication requirement is "UL bandwidth that needs to be guaranteed is 80 Mbps or more and 100 Mbps or less," the control policy is "guarantee a bandwidth of 100 Mbps in UL."

[0223] For example, if the communication requirement is "allowable delay of 40 ms or less," the control policy is "allowable communication delay of up to 20 ms" and "enable optimization of beamforming in the direction of the moving route."

[0224] Here, the SMO 310 acquires a communication requirement of "guaranteeing a bandwidth of 90 Mbps in UL." The SMO 310 refers to the configuration file and converts this communication requirement to "guaranteeing a bandwidth of 100 Mbps in UL."

[0225] In this way, the SMO 310 generates a control policy by applying the converted rules read from the configuration file to the acquired communication requirements.

[0226] The configuration file may be rewritten by an administrator, or may be rewritten autonomously using a rule-based algorithm, AI, or the like, taking into consideration the content requested by the client (for example, the content of the communication requirements notified from the terminal device 100) and the communication usage status of the cellular network.

[0227] The SMO 310 notifies the NearRT-RIC 320 of the converted control policy (here, "guarantee bandwidth of 100 Mbps in UL") via the Non-NearRT-RIC 311 (step S48).

[0228] (Calculation of RAN parameters) The NearRT-RIC 320 calculates RAN parameters from the control policy. For example, the NearRT-RIC 320 has conversion rules (e.g., calculation formulas, correspondence tables, etc.) for calculating RAN parameters for each control policy. The NearRT-RIC 320 calculates the RAN parameters in accordance with these conversion rules.

[0229] For example, when a UL bandwidth guarantee is notified as a communication requirement (control policy), the NearRT-RIC 320 calculates the RAN parameters using the following calculation formula.

[0230] Allocation ratio = (UL throughput + OFFSET) / (total RBs * number of bits per RB)

[0231] Here, the allocation ratio is the allocation ratio of UL slots to DL slots. The UL throughput is the UL throughput to be guaranteed calculated from communication requirements and is notified as policy information. The offset is an arbitrary value that is set appropriately depending on conditions, etc. The total RB is the total number of resource blocks.

[0232] When the NearRT-RIC 320 is notified of UL bandwidth guarantee as a control policy, it calculates the RAN parameters based on the above-mentioned calculation formula.

[0233] For example, when an allowable delay is notified as a communication requirement (control policy), NearRT-RIC 320 calculates the upper limit of the number of retransmissions and the upper limit of the retransmission timer (Reordering Timer) as RAN parameters using the following calculation formula.

[0234] Retransmission limit = (allowable delay time - offset - processing time - delay time) / communication time per transmission Retransmission timer limit = allowable delay time - offset - average transmission delay

[0235] Here, the allowable delay time is the allowable delay calculated from the communication requirements and is notified as policy information. The processing time is the processing time for the schedule request. The delay time is the delay time until the time slot is allocated. The communication time for one communication is the time from when data is transmitted until an ACK / NACK is notified. The offset is an arbitrary value that is set appropriately depending on the conditions, etc.

[0236] When the NearRT-RIC 320 is notified of the allowable delay as a control policy, it calculates the upper limit of the number of retransmissions and the upper limit of the reordering timer as RAN parameters based on the above-mentioned calculation formula.

[0237] For example, when reliability is notified as a communication requirement (control policy), the NearRT-RIC 320 calculates the upper limit of the number of retransmissions as a RAN parameter using the following calculation formula.

[0238] Maximum number of retransmissions = Floor (log 10 (target packet loss rate) / log 10 (Communication packet loss rate)

[0239] Here, the target packet loss rate is the packet loss rate calculated from the communication requirements and is notified as policy information. The communication packet loss rate is the packet loss rate in one communication. Also, Floor means rounding down the value using the Floor function.

[0240] When the NearRT-RIC 320 is notified of reliability as a control policy, it calculates the upper limit of the number of retransmissions as a RAN parameter based on the above-mentioned calculation formula.

[0241] In addition, when NearRT-RIC320 is notified of reliability (e.g., a target SNR (Signal-to-Noise Ratio) value) as a control policy, it determines the upper limit of the MCS, for example, from a correspondence table of upper limit MCS values ​​for SNR value ranges.

[0242] Note that the calculation of the RAN parameters is not limited to the method using the above-described calculation formula, etc. For example, the NearRT-RIC 320 may calculate the RAN parameters from the communication requirements and / or the control policy using a learning model.

[0243] For example, the learning model is a model that learns RAN parameters that stably realize each communication requirement and is prepared in advance. Specifically, for example, the learning model is a model that strategically learns RAN parameters that stably satisfy each communication requirement (and / or control policy) using a reinforcement learning algorithm or the like.

[0244] The learning model may be trained using an algorithm other than a reinforcement learning algorithm, such as a machine learning algorithm such as a linear regression or a support vector machine (SVM), or a deep learning algorithm such as a recurrent neural network (RNN), a long short-term memory (LSTM), or a transformer.

[0245] For example, examples of reinforcement learning include Q-Learning, State-Action-Reward-State-Action (SARSA), and policy gradient methods.

[0246] For example, the learning model takes communication requirements (and / or control policies) as input and RAN parameters as output. The NearRT-RIC 320 calculates the RAN parameters by inputting the communication requirements (and / or control policies) into the learning model.

[0247] Note that, similarly to the RAN parameters, the control policy may be calculated from a learning model. In this case, the SMO 310 calculates the control policy using, for example, a learning model that takes communication requirements as input and outputs the control policy.

[0248] (RAN parameter notification process) Figure 14 is a sequence diagram showing an example of the flow of a RAN parameter notification process according to an embodiment of the present disclosure. The notification process shown in Figure 14 is executed, for example, after the communication process of Figure 12 is executed and before communication between the terminal device 100 and the base station 300 is started. Alternatively, the communication process may be executed after the SMO 310 calculates the control policy.

[0249] The NearRT-RIC 320 derives RAN parameters from the control policy acquired from the SMO 310 (step S301).

[0250] Next, the NearRT-RIC 320 controls various resources for the CU 330 / DU 340 (step S302).

[0251] The NearRT-RIC 320 controls the RAN parameters for the RU 350 or the CU 330 / DU 340 (step S303).

[0252] This notification process is executed for each of one or more communication requirements.

[0253] <3-2. Communication Phase> Next, an example of communication processing in the communication phase will be described. When the communication processing in the allocation phase ends, the communication processing in the communication phase starts. More specifically, for example, when a packet is generated in the terminal device 100, the communication processing in the communication phase starts.

[0254] (Communication Start Processing) First, in the communication system, a communication start processing is executed as a communication processing in the communication phase.

[0255] 15 is a sequence diagram illustrating an example of a flow of a communication start process according to an embodiment of the present disclosure. The communication start process illustrated in FIG. 15 is executed by a communication system when a packet is generated in a terminal device 100 (hereinafter also referred to as UE 100).

[0256] When a packet is generated in the UE 100 (step S311), the UE 100 determines the communication requirements of this packet (step S312).

[0257] The UE 100 transmits this packet to the base station 300 (more specifically, the RU 350) connected thereto as a packet that needs to satisfy the communication requirements (step S313).

[0258] The RU 350 that receives the packet transmits the packet to the CU 330 / DU 340 (step S314).

[0259] The CU 330 / DU 340 (or NearRT-RIC 320) determines whether communication of this packet is being performed via a desired base station 300 (step S315). For example, the CU 330 / DU 340 determines whether a base station 300 (more specifically, a DU 340 connected to the RU 350) in which RAN parameters corresponding to the communication requirements to be satisfied for this packet are set is connected to the UE 100.

[0260] The CU 330 / DU 340 refers to the requirement DBs 331 and 341 and determines whether the packet is being communicated via the desired base station 300 based on the BS identification information and the like.

[0261] If this packet is not being communicated via the desired base station 300, the CU 330 / DU 340 (or NearRT-RIC 320) performs handover to the desired base station 300 (step S316).

[0262] If the packet is being communicated via the desired base station 300, the CU 330 / DU 340 transmits the packet to the communication partner of the UE 100 (step S317).

[0263] In this manner, UL communication is performed in which packets are transmitted from the UE 100 to the communication partner. Next, DL communication in which packets are transmitted from the communication partner to the UE 100 will be described.

[0264] As shown in FIG. 15, the communication partner transmits a packet that needs to satisfy the communication requirements to the CU 330 / DU 340 (step S318).

[0265] The CU 330 / DU 340 (or NearRT-RIC 320) determines whether communication of this packet is being performed via a desired base station 300 (step S319). For example, the CU 330 / DU 340 (or NearRT-RIC 320) determines whether a base station 300 (more specifically, RU 350 or CU 330 / DU 340) in which RAN parameters according to the communication requirements to be satisfied for this packet are set is connected to the UE 100.

[0266] The CU 330 / DU 340 refers to the requirement DBs 331 and 341 and determines whether the packet is being communicated via the desired base station 300 based on the BS identification information and the like.

[0267] If the packet is not being communicated via the desired base station 300, the CU 330 / DU 340 (or NearRT-RIC 320) performs handover to the desired base station 300 (step S320).

[0268] If the packet is being communicated via the desired base station 300, the CU 330 / DU 340 transmits the packet to the RU 350 (step S321).

[0269] The RU 350 transmits a packet to the UE 100 so as to satisfy the communication requirements (step S322).

[0270] Here, the UE 100 connects to a surrounding base station 300, for example, at the time of startup. At this time, the base station 300 to which the UE 100 connects is not necessarily the base station 300 reserved in the allocation phase.

[0271] For example, there is a case where the required communication requirements are not determined until a packet is generated in the UE 100. In this case, the UE 100 cannot determine which of the reserved base stations 300 to connect to.

[0272] In this way, when transmitting a packet, the UE 100 is not necessarily connected to the base station 300 that satisfies the communication requirements required for this packet.

[0273] Therefore, in this embodiment, CU330 / DU340 (or NearRT-RIC320) determines whether UE100 is connected to a base station 300 that meets the communication requirements for the packet, and if they are not connected, performs a handover to a base station 300 that meets the communication requirements.

[0274] This allows UE 100 to perform handover to base station 300 even if it is not connected to base station 300 that can perform communication that satisfies the desired communication requirements, and allows UE 100 to perform communication that satisfies the desired communication requirements.

[0275] (Outline of handover process) As described above, when the UE 100 is not connected to a desired base station 300, that is, a base station 300 reserved for communication that satisfies desired communication requirements (a base station 300 to which communication requirements are assigned), a handover is performed.

[0276] Furthermore, handover may be performed even when connected to the desired base station 300. For example, handover is performed when it is determined that the desired communication requirements cannot be met in communication with the desired base station 300. This point will be described with reference to FIGS.

[0277] 16 to 18 are diagrams illustrating an overview of handover processing according to an embodiment of the present disclosure.

[0278] 16, it is assumed that four base stations 300_B1 to 300_B3 and 300_C are reserved by server device 200 as one set 10. For example, different communication requirements are assigned to base stations 300_B1 to 300_B3. Furthermore, base station 300_C is reserved as a spare base station 300.

[0279] The UE 100_1 performs communication with at least one of the base stations 300_B1 to 300_B3 that satisfies at least one of one or more communication requirements. In the example of Fig. 16, the UE 100_1 performs communication with each of the base stations 300_B1 to 300_B3 that satisfies each of the three communication requirements.

[0280] Specifically, the UE 100_1 communicates with the base station 300_B1 in a manner that satisfies the first communication requirement (step S50). That is, the base station 300_B1 is the base station 300 to which the first communication requirement is assigned. The base station 300_B1 is the base station 300 that has been reserved in advance to communicate with the UE 100_1 in a manner that satisfies the first communication requirement.

[0281] For example, the first communication requirement is high-capacity communication. As described above, for example, when the UE 100_1 transmits an image captured by a high-definition camera, communication that satisfies the high-capacity communication requirement is required.

[0282] In this case, for example, in order to realize high-capacity communication in the UL direction, a RAN parameter for optimizing high-capacity communication is set in the base station 300_B1. For example, the base station 300_B1 changes the allocation ratio so that the UL / DL slot ratio (allocation ratio of UL slots to DL slots) becomes high, and communicates with the UE 100_1.

[0283] The UE 100_1 communicates with the base station 300_B2 satisfying the second communication requirement (step S51). That is, the base station 300_B2 is the base station 300 to which the second communication requirement is assigned. The base station 300_B2 is the base station 300 that has been reserved in advance for communicating with the UE 100_1 satisfying the second communication requirement.

[0284] For example, the second communication requirement is low-latency communication. As described above, for example, when the UE 100_1 transmits control information for a remote surgery arm, communication that satisfies the low-latency communication requirement is required.

[0285] In this case, for example, RAN parameters for optimizing low-latency communication are set in the base station 300_B2 to realize low-latency communication. For example, the base station 300_B2 communicates with the UE 100_1 by directing a beam (beamforming) toward the UE 100_1. The base station 300_B2 controls the beam so that it always faces the UE 100_1, for example, according to the location information and movement route of the UE 100_1.

[0286] The UE 100_1 communicates with the base station 300_B3 satisfying the third communication requirement (step S52). That is, the base station 300_B3 is the base station 300 to which the third communication requirement is assigned. The base station 300_B3 is the base station 300 that has been reserved in advance for communicating with the UE 100_1 satisfying the third communication requirement.

[0287] For example, a third communication requirement is high-reliability communication. As described above, for example, when the UE 100_1 periodically transmits the sensing result of the vital sensor, communication that satisfies the high-reliability communication requirement is required.

[0288] In this case, for example, in order to realize highly reliable communication, RAN parameters for optimizing highly reliable communication are set in the base station 300_B3. For example, the base station 300_B3 communicates with the UE 100_1 by lowering the MCS value.

[0289] Furthermore, the base station 300_C is a spare base station 300 that performs communication in place of the base stations 300_B1 to 300_B3 when the base stations 300_B1 to 300_B3 are no longer able to perform communication that satisfies the communication requirements.

[0290] When the base station 300_C does not communicate with the UE 100_1, the base station 300_C may communicate with one or more other UEs 100_2 and 100_3 (step S53). Note that the base station 300_A is a base station 300 to which communication requirements are not assigned and which is not a spare base station 300, in other words, a base station 300 not included in the set 10 of base stations 300.

[0291] In this way, the UE 100_1 can communicate with a plurality of base stations 300 simultaneously while satisfying different communication requirements for each base station.

[0292] At this time, it is conceivable that the communication requirements may not be satisfied in the communication between the UE 100_1 and the base station 300. For example, the communication requirements may not be satisfied due to deterioration of the communication environment or the like.

[0293] In this case, the UE 100_1 performs handover and continues communication that satisfies the communication requirements by switching to the backup base station 300. This handover can be divided into, for example, a first method in which the base station 300 is mainly executed, and a second method in which the UE 100_1 is mainly executed.

[0294] (First Method) A first method in which the base station 300 determines whether to perform a handover will be described with reference to Fig. 17. The base station 300 issues a handover instruction to the UE 100 and the handover destination base station 300. Note that the same components and processes as those in Fig. 16 are designated by the same reference numerals, and their description will be omitted.

[0295] Here, it is assumed that the communications between the base stations 300_B1 and 300_B2 and the UE 100_1 satisfy the first and second communication requirements, and that the communications between the base station 300_B3 and the UE 100_1 no longer satisfy the third communication requirement.

[0296] The base station 300_B3 detects, based on a change in communication quality or the like, that communication that satisfies the third communication requirement cannot be performed, in other words, that the third communication requirement cannot be guaranteed (step S54).

[0297] The base station 300_B3 notifies the backup base station 300_C of an operation request and executes handover with the backup base station 300_C (step S55). At this time, the NearRT-RIC 320 replicates the RAN parameters according to the third communication requirement, in other words, the RAN parameters set in the base station 300_B3, to the backup base station 300_C.

[0298] The base station 300_C also stops (or disconnects) communication with the UE 100_2 and the UE 100_3 with which it has been communicating (step S56), and executes handover. After executing the handover, the base station 300_C communicates with the UE 100_1 (step S57).

[0299] In this way, the communication system according to this embodiment assigns the third communication requirement, which was assigned to the base station 300_B3 that had been performing communication up until then, to the spare base station 300_C, causing it to perform communication with the UE 100_1.

[0300] As a result, even if UE100_1 is no longer able to communicate with base station 300_B3, to which the third communication requirement has been assigned in advance, in a manner that satisfies the third communication requirement, UE100_1 can still communicate with backup base station 300_C in a manner that satisfies the third communication requirement.

[0301] The UE 100_1 can stably continue communication that satisfies the desired communication requirements.

[0302] (Second Method) A second method in which UE 100 determines whether to perform handover will be described with reference to Fig. 18. UE 100 requests handover from destination base station 300 via server device 200. Note that the same components and processes as those in Fig. 17 are designated by the same reference numerals, and description thereof will be omitted.

[0303] Here, it is assumed that the communications between the base stations 300_B1 and 300_B2 and the UE 100_1 satisfy the first and second communication requirements, and that the communications between the base station 300_B3 and the UE 100_1 no longer satisfy the third communication requirement.

[0304] The UE 100_1 detects, from a change in communication quality or the like, that communication that satisfies the third communication requirement cannot be performed, in other words, that the third communication requirement cannot be guaranteed (step S61).

[0305] The UE 100_1 requests the server device 200 to perform handover to the spare base station 300_C (step S62). The server device 200 notifies the spare base station 300_C of an operation request (step S63).

[0306] As a result, the backup base station 300_C stops (or disconnects) communication with the other UEs 100_2 and 100_3, and executes handover with the base station 300_B3.

[0307] After the handover, the base station 300_C performs communication with the UE 100_1 that satisfies the third communication requirement, based on the RAN parameters according to the third communication requirement replicated from the RIC (for example, NearRT-RIC 320).

[0308] In this way, the UE 100_1, which has determined that the communication requirements cannot be satisfied, requests handover to the backup base station 300_C via the server device 200. This allows the UE 100_1 to stably continue communication that satisfies the desired communication requirements.

[0309] It is assumed that the communication quality with the base station 300_B3 (the handover source base station 300) with which the UE 100_1 originally communicated is recovered while the UE 100_1 is communicating with the backup base station 300_C (the handover destination base station 300). In other words, it is assumed that the base station 300_B3 can communicate with the UE 100_1 satisfying the third communication requirement.

[0310] In this case, the UE 100_1 may perform handover from the spare base station 300_C to the base station 300_B3. In this way, when communication satisfying the third communication requirement becomes possible with the originally assigned base station 300_B3, the UE 100_1 can switch communication from the spare base station 300_C to the base station 300_B3.

[0311] 19 is a sequence diagram illustrating an example of a flow of a handover process according to an embodiment of the present disclosure. The handover process illustrated in FIG. 19 is executed when the UE 100 and the base station 300 are communicating with each other.

[0312] When a packet is generated in the UE 100 (step S401), the UE 100 determines the communication requirements of this packet (step S402).

[0313] The UE 100 transmits this packet to the base station 300 (more specifically, the RU 350) connected thereto as a packet that must satisfy the communication requirements (step S403).

[0314] The RU 350 that receives the packet transmits the packet to the CU 330 / DU 340 (step S404).

[0315] Here, for example, if the base station 300 (e.g., the CU 330 / DU 340) determines that it cannot satisfy the desired communication requirements, the CU 330 / DU 340 transmits a request to the NearRT-RIC 320 to change the network parameters of the standby RU 350 (step S405). The CU 330 / DU 340 transmits a handover request to the standby RU 350 by transmitting this request to change the network parameters.

[0316] Alternatively, the NearRT-RIC 320 may determine whether the base station 300 (e.g., the CU 330 / DU 340) is unable to meet the desired communication requirements.

[0317] The NearRT-RIC 320 controls the network parameters of the standby RU 350 (step S406). For example, the NearRT-RIC 320 controls the RAN parameters of the standby RU 350, which were previously controlled by the RU 350.

[0318] The NearRT-RIC 320 transmits a control start notification to the CU 330 / DU 340 indicating that control of the network parameters for the standby RU 350 has begun (step S407).

[0319] Upon receiving the control start notification, the CU 330 / DU 340 performs handover to the standby RU 350 (step S408).

[0320] The CU 330 / DU 340 may transmit the packet received in step S404 to the communication partner. This packet transmission may be performed before or after the handover.

[0321] On the other hand, for example, when the UE 100 determines that the desired communication requirements cannot be satisfied, the UE 100 transmits a handover request to the Server 200 (step S409).

[0322] The Server 200 transmits a handover request to the NearRT-RIC 320 to the spare RU 350 (step S410). For example, the Server 200 requests the NearRT-RIC 320 to perform a handover via the SMO 310.

[0323] The subsequent processing is the same as when the base station 300 determines whether to perform a handover, so the same reference numerals are used and the description thereof will be omitted.

[0324] When the handover is completed, the UE 100 communicates with the RU 350. Specifically, when a packet is generated in the UE 100 (step S411), the UE 100 determines the communication requirements of this packet (step S412).

[0325] The UE 100 transmits this packet to the backup base station 300 (more specifically, the backup RU 350) to which it is connected, as a packet that needs to satisfy the communication requirements (step S413).

[0326] The spare RU 350 that receives the packet transmits the packet to the CU 330 / DU 340 (step S414). The CU 330 / DU 340 transmits the received packet to the communication partner (step S415).

[0327] As described above, when the communication requirements required by the UE 100 and the communication requirements guaranteed by the connected base station 300 differ, that is, when the base station 300 does not guarantee the desired communication requirements, the UE 100 performs handover to another base station 300. Furthermore, when the connected base station 300 becomes unable to satisfy the desired communication requirements due to the influence of degradation of the communication environment or the like, the UE 100 performs handover to a backup base station 300.

[0328] At this time, by reserving in advance a base station 300 to be allocated for each communication requirement, the UE 100 can smoothly perform handover to the base station 300 that ensures the desired communication requirement. Also, by reserving in advance a spare base station 300, the UE 100 can smoothly perform handover to the spare base station 300 even when the desired communication requirement cannot be satisfied.

[0329] This allows the communication system to prevent the handover destination base station 300 from being unable to secure resources and satisfy communication requirements, for example.

[0330] In this way, the communication system according to this embodiment can guarantee one or more communication requirements at a higher level by handing over the UE 100 to a set of reserved base stations 300 .

[0331] (Specific Examples of Handover) Handover between base stations 300 is classified into several types. Specific examples of each type of handover will be described below.

[0332] (Intra-gNB DU Handover) Fig. 20 is a diagram illustrating an example of handover according to an embodiment of the present disclosure. Fig. 20 illustrates an example of handover when the handover destination base station 300 is within the same DU 340, that is, so-called Intra-gNB DU Handover.

[0333] In FIG. 20, UE 100 performs handover from a handover source RU 350 (hereinafter also referred to as Source RU 350_S) connected to the same DU 340_1 to a handover destination RU 350 (hereinafter also referred to as Target RU 350_T).

[0334] That is, the Source RU 350_S is the RU 350 currently connected to the UE 100, and the Target RU 350_T is the desired RU 350 (for example, an RU 350 that satisfies the communication requirements or a spare RU 350).

[0335] FIG. 21 is a sequence diagram illustrating an example of a flow of handover according to an embodiment of the present disclosure.

[0336] As shown in Fig. 21, the UE 100 performs data communication with the Source RU 350_S (step S501), and the Source RU 350_S performs data communication with the CU 330 (step S502).

[0337] Here, when the CU 330 (or NearRT-RIC 320) determines to perform handover, it acquires BS identification information of the desired base station 300 (for example, a base station 300 that satisfies the communication requirements or a spare base station 300) that is the handover destination (step S503). For example, the CU 330 refers to the requirements DB 331 to acquire the BS identification information of the base station 300 that satisfies the desired communication requirements or the spare base station 300.

[0338] Next, the CU 330 performs DL RRC Message Transfer to the DU 340_1 (step S504). The DU 340_1 transmits UL RRC Message Transfer to the CU 330 (step S505).

[0339] The CU 330 transmits a UE Context Modification Request to the DU 340_1 (step S506). The DU 340_1 transmits a UE Context Modification Response to the CU 330 (step S507). The CU 330 transmits a DL RRC Message Transfer to the DU 340_1 (step S508).

[0340] Subsequently, the DU 340_1 specifies the BS identification information of the desired base station 300 to the UE 100 and performs RRCReconfiguration (step S509).

[0341] The UE 100 makes an inquiry to the Target RU 350_T for response confirmation (step S510), and acquires a response from the Target RU 350_T (step S511).

[0342] The UE 100 notifies the CU 330 of the success of the connection with the Target RU 350_T (step S512), and receives a response from the CU 330 (step S513).

[0343] The UE 100 transmits an RRCReconfigurationComplete to the DU 340_1 (step S514). The DU 340_1 transmits an UL RRC Message Transfer to the CU 330 (step S515), and the Intra-gNB DU Handover is completed.

[0344] Thereafter, the UE 100 performs data communication with the Target RU 350_T (step S516).

[0345] (Intra-gNB CU Handover) Fig. 22 is a diagram showing another example of handover according to an embodiment of the present disclosure. Fig. 20 shows an example of handover when the handover destination base station 300 is within the same CU 330, that is, so-called Intra-gNB CU Handover.

[0346] In Figure 22, UE100 performs a handover from Source RU350_S connected to DU340 (hereinafter also referred to as Source DU340_S), which is the source of handover and is connected to the same CU330, to Target RU350_T connected to DU340 (hereinafter also referred to as Target DU340_T), which is the destination of handover.

[0347] 23 is a sequence diagram showing another example of the flow of handover according to the embodiment of the present disclosure. Note that, among the handover processes shown in FIG. 23, the same processes as those in FIG. 21 are denoted by the same reference numerals, and descriptions thereof will be omitted.

[0348] The CU 330 transmits a UE Context Setup Request to the Source RU 350_S (step S601), and the Source RU 350_S transmits a UE Context Setup Response to the CU 330 (step S602).

[0349] The CU 330 sends a UE Context Modification Request to the Source DU 340_S (step S603).

[0350] Subsequently, the Source DU 340_S specifies the BS identification information of the desired base station 300 to the UE 100 and performs RRCReconfiguration (step S604).

[0351] The Source DU 340_S transmits a UE Context Modification Response to the CU 330 (step S605).

[0352] The UE 100 makes an inquiry to the Target RU 350_T for response confirmation (step S606), and acquires a response from the Target RU 350_T (step S607).

[0353] The UE 100 notifies the Target DU 340_T of the success of the connection with the Target RU 350_T (step S608), and obtains a response from the Target DU 340_T (step S609).

[0354] The UE 100 transmits an RRCReconfigurationComplete to the Target DU 340_T (Step S610). The Target DU 340_T transmits an UL RRC Message Transfer to the CU 330 (Step S611).

[0355] The CU 330 transmits a UE Context Release Command to the Source RU 350_S (step S612). The Source RU 350_S transmits a UE Context Release Complete to the CU 330 (step S613), and the Intra-gNB CU Handover is completed.

[0356] (Xn Handover) Fig. 24 is a diagram showing another example of handover according to an embodiment of the present disclosure. Fig. 24 shows an example of handover when the handover destination base station 300 is in a different CU 330, that is, so-called Xn Handover.

[0357] In FIG. 24, UE 100 performs handover from Source RU 350_S connected to CU 330 (hereinafter also referred to as Source CU 330_S) which is the source of handover, to Target RU 350_T connected to CU 330 (hereinafter also referred to as Target CU 330_T) which is the destination of handover.

[0358] In FIG. 24, the Source CU 330_S and the Target CU 330_T are connected via an Xn interface.

[0359] 25 is a sequence diagram showing another example of the flow of handover according to the embodiment of the present disclosure. Note that, among the handover processes shown in FIG. 25, the same processes as those in FIG. 23 are denoted by the same reference numerals, and descriptions thereof will be omitted.

[0360] The Source CU330_S / DU340_S transmits a Handover Request to the Target CU330_T / DU340_T (step S701). The Target CU330_T / DU340_T transmits a Handover Request Ack to the Source CU330_S / DU340_S (step S702).

[0361] Next, the Source CU330_S / DU340_S specifies the BS identification information of the desired base station 300 to the UE100 and performs RRCReconfiguration (step S703).

[0362] The Source CU330_S / DU340_S transmits an SN Status Transfer to the Target CU330_T / DU340_T (step S704).

[0363] The UE 100 makes an inquiry to the Target RU 350_T for response confirmation (step S705), and acquires a response from the Target RU 350_T (step S706).

[0364] The UE 100 notifies the Target CU 330_T / DU 340_T of the success of the connection with the Target RU 350_T (step S707), and obtains a response from the Target CU 330_T / DU 340_T (step S708).

[0365] The UE 100 transmits an RRCReconfigurationComplete to the Target CU 330_T / DU 340_T (step S709). The Target CU 330_T / DU 340_T transmits a PathSwichRequest to the 5G Core 400 (step S710), and acquires a PathSwichRequestAck from the 5G Core 400 (step S711).

[0366] The Target CU330_T / DU340_T sends a UE Context Release to the Source CU330_S / DU340_S (step S712), and the Xn Handover is completed.

[0367] (N2 Handover) Fig. 26 is a diagram showing another example of handover according to an embodiment of the present disclosure. Fig. 26 shows an example of handover when the handover destination base station 300 is in a different CU 330, that is, so-called N2 Handover.

[0368] The example of Figure 26 is the same as the example of Figure 24 in that the base station 300 to which handover is directed is located in a different CU330, but differs from the example of Figure 24 in that the different CU330 (Source CU330_S and Target CU330_T) are not connected by an Xn interface.

[0369] In the example of FIG. 26, the Source CU330_S and the Target CU330_T are connected to each other via the AMF420 (5G Core400).

[0370] 27 is a sequence diagram showing another example of the flow of handover according to the embodiment of the present disclosure. Note that, among the handover processes shown in FIG. 27, the same processes as those in FIG. 25 are denoted by the same reference numerals, and descriptions thereof will be omitted.

[0371] The Source CU330_S / DU340_S transmits a HandoverRequired to the 5G Core 400 (step S801). The 5G Core 400 transmits a HandoverRequest to the Target CU330_T / DU340_T (step S802). The Target CU330_T / DU340_T transmits a Handover RequestAck to the 5G Core 400 (step S803).

[0372] The 5G Core 400 transmits a Handover Command to the Source CU 330_S / DU 340_S (step S804).

[0373] Next, the Source CU330_S / DU340_S specifies the BS identification information of the desired base station 300 to the UE100 and performs RRCReconfiguration (step S805).

[0374] The Source CU330_S / DU340_S transmits an UplinkRANStatusTransfer to the 5G Core 400 (step S806). The 5G Core 400 transmits a DownlinkRANStatusTransfer to the Source CU330_S / DU340_S (step S807).

[0375] The UE 100 makes an inquiry to the Target RU 350_T for response confirmation (step S808), and acquires a response from the Target RU 350_T (step S809).

[0376] The UE 100 notifies the Target CU 330_T / DU 340_T of the success of the connection with the Target RU 350_T (step S810), and obtains a response from the Target CU 330_T / DU 340_T (step S811).

[0377] The UE 100 transmits an RRCReconfigurationComplete to the Target CU 330_T / DU 340_T (step S812). The Target CU 330_T / DU 340_T transmits a HandoverNotify to the 5G Core 400 (step S813).

[0378] The 5G Core 400 transmits a UEContextReleaseCommand to the Source CU 330_S / DU 340_S (step S814). The Source CU 330_S / DU 340_S transmits a UEContextReleaseComplete to the 5G Core 400 (step S815), and the N2 Handover is completed.

[0379] In this way, the handover source base station 300 (e.g., Source CU 330_S) acquires BS identification information that identifies the desired (handover destination) base station 300. Furthermore, the handover source base station 300 (e.g., Source DU 340_S) specifies the desired base station 300 and performs RRC Reconfiguration.

[0380] As a result, the UE 100 can perform handover to the base station 300 that satisfies the desired communication requirements, and can stably continue communication that satisfies the desired communication requirements.

[0381] (Change of communication requirements) In the allocation phase, the communication requirements notified by the UE 100 may be changed in the communication phase. For example, when the image quality of the high-definition camera is changed, a change of the communication requirements may be required in accordance with this change.

[0382] An example of a change process when the communication requirements are changed in this way will be described.

[0383] (Overview of Change Processing) Fig. 28 is a diagram showing an overview of a change processing of a communication requirement according to an embodiment of the present disclosure. In Fig. 28, the same components as those in Fig. 16 are assigned the same reference numerals, and description thereof will be omitted.

[0384] Here, a case will be described in which the UE 100_1 changes the communication requirement for communication with the base station 300_B2 from the second communication requirement to the fourth communication requirement.

[0385] First, the UE 100_1 notifies the server device 200 of a change request (step S71). The change request includes, for example, requirement identification information for identifying a communication requirement to be changed (here, the second communication requirement) and information on the communication requirement after the change (here, the fourth communication requirement).

[0386] Next, in response to the change request, the server device 200 notifies the base station 300 (here, the base station 300_B2) that is performing communication satisfying the communication requirement to be changed of a request to change the communication requirement (step S72). In response to this, the base station 300_B2 changes the network parameters (RAN parameters) in accordance with the fourth communication requirement.

[0387] When the base station 300_B2 completes the change of the communication requirements (more specifically, the RAN parameters), the server device 200 transmits a change completion notification to the UE 100_1 (step S73). The change completion notification may include, for example, requirement identification information for identifying the changed communication requirements.

[0388] Thereafter, the UE 100_1 performs communication with the base station 300_B2 that satisfies the fourth communication requirement (step S74).

[0389] (Details of Change Processing) FIG. 29 is a sequence diagram showing an example of the flow of a change processing of a communication requirement according to an embodiment of the present disclosure.

[0390] 29 , the UE 100 notifies the Server 200 of a request to change the communication requirements (step S901). The change request may include, for example, BS identification information for identifying the base station 300 whose communication requirements are to be changed, and information on the changed communication requirements.

[0391] Based on the change request, the server 200 determines the 5G core 400 to which the change of the communication requirement is to be requested (step S902). For example, the server 200 determines the 5G core 400 to which the base station 300 whose communication requirement is to be changed belongs as the destination of the change request, based on the BS identification information included in the change request.

[0392] The server 200 notifies the SMO 310 of the change request via the determined 5G core 400 (step S903). The change request includes, for example, at least one of terminal identification information for identifying the UE 100, BS identification information, and information on the communication requirements after the change.

[0393] The SMO 310 refers to the BS DB 312 using the BS identification information included in the change request, and acquires BS information related to the base station 300 for which communication requirements are to be changed (step S904).

[0394] The SMO 310 calculates a control policy for RIC based on the communication requirements to be assigned to the base station 300 (step S905). The SMO 310 calculates the control policy in the same manner as the control policy calculation process described with reference to FIGS. 12 and 13, for example.

[0395] The SMO 310 notifies the NearRT-RIC 320 of change information including policy information related to the calculated control policy (step S906). The SMO 310 notifies the NearRT-RIC 320 of the change information via, for example, the Non-NearRT-RIC 311. The change information includes, for example, policy information related to the control policy corresponding to the changed communication requirements, and terminal identification information.

[0396] The NearRT-RIC 320 determines whether the terminal identification information of the UE 100 connected to the base station 300 for which the communication requirements are to be changed matches the terminal identification information included in the change information (step S907).

[0397] If the terminal identification information matches, the NearRT-RIC 320 updates the policy information in the requirement DB 321 (step S908).

[0398] The NearRT-RIC 320 notifies each CU 330 / DU 340 of the replication of the requirements DB 321 (step S909). For example, the NearRT-RIC 320 notifies all connected CUs 330 and DUs 340 of the replication of the requirements DB 321 by notifying them of policy information.

[0399] The CU 330 / DU 340 maintains a replication of the requirement DB 321 (step S910). For example, the CU 330 and DU 340 maintain a replication of the requirement DB 321 by updating the policy information of the requirement DBs 331 and 341.

[0400] Note that when the NearRT-RIC 320 generates the RAN parameters from the policy information, the RAN parameters are not converted from the policy information in the CU 330 / DU 340. In this case, steps S909 and S910 may be omitted.

[0401] The NearRT-RIC 320 derives RAN parameters from the control policy acquired from the SMO 310 (step S911).

[0402] Next, the NearRT-RIC 320 controls various resources for the CU 330 / DU 340 (step S912).

[0403] The NearRT-RIC 320 controls the RAN parameters for the RU 350 (step S913).

[0404] The NearRT-RIC 320 notifies the SMO 310 of the success of the change in the communication requirements (step S914). The SMO 310 notifies the Server 200 of the success of the change in the communication requirements (step S915). The Server 200 notifies the UE 100 of the success of the change in the communication requirements (step S916).

[0405] This completes the change in the communication requirements of the base station 300.

[0406] On the other hand, if the terminal identification information does not match, the NearRT-RIC 320 notifies the SMO 310 of a failure to change the communication requirements (step S917). The SMO 310 notifies the Server 200 of a failure to change the communication requirements (step S918). The Server 200 notifies the UE 100 of a failure to change the communication requirements (step S919).

[0407] In this manner, the UE 100_1 can update the communication requirements by requesting the server apparatus 200 to change the communication requirements.

[0408] Thereby, the UE 100_1 can perform optimal communication in accordance with, for example, changing communication requirements with the base station 300. Therefore, the communication system can provide the UE 100 with communication that satisfies the required communication requirements more stably in terms of time axis.

[0409] <3-3. Communication Involving Movement> For example, when the UE 100 is a moving body such as an emergency vehicle, it may be required to perform communication that satisfies one or more communication requirements while moving.

[0410] In this case, the server device 200 prepares in advance a plurality of sets of one or more base stations 300 according to the movement route of the UE 100. When the UE 100 starts moving, the UE 100 performs communication that satisfies the communication requirements with the set of base stations 300 according to the time and / or its own location.

[0411] That is, the UE 100 updates the set of base stations 300 according to the time and / or its own location, and updates the base station 300 to which it is connected. By updating the set of base stations 300, the base stations 300 to which the same communication requirements are assigned are updated. The UE 100 performs handover from the base station 300 before the update to the base station 300 after the update according to the time and / or its own location.

[0412] This allows the UE 100 to stably perform communication that satisfies the communication requirements even when the UE 100 is moving.

[0413] (Outline of Communication Processing) FIG. 30 is a diagram illustrating another example of communication processing in the allocation phase according to an embodiment of the present disclosure.

[0414] The UE 100 notifies the server device 200 of notification information including route information regarding the moving route P1 (step S81). The notification information is the same as the communication processing described with reference to FIG. 8 except that the notification information includes the route information regarding the moving route P1.

[0415] For example, the server device 200 creates multiple pairs of base stations 300 by requesting the 5G Core 400 to reserve the base station 300 by specifying the location and communication requirements of the UE 100.

[0416] 30, the server device 200 generates three sets 10_1 to 10_3 (step S82). Set 10_1 includes base stations 300_B1 to 300_B4. Set 10_2 includes base stations 300_B3, and 300_B5 to 300_B7. Set 10_3 includes base stations 300_B3, 300_B4, 300_B7, and 300_B8.

[0417] Note that the sets 10 shown in Fig. 30 are just an example, and the sets 10 are not limited to the example of Fig. 30. For example, the number of sets 10 generated by the server device 200 may be two or less or four or more.

[0418] The number of base stations 300 included in one set 10 may be three or less or five or more. The number of base stations 300 included in each set 10 may be the same or different. The communication requirements assigned to each set 10 may be different.

[0419] Also, in FIG. 30, at least some of the base stations 300 in each set 10 overlap, but the base stations 300 in each set 10 may all be different.

[0420] The base station 300_A is a base station 300 to which communication requirements are not assigned and which is not a spare base station 300, in other words, a base station 300 not included in the set 10 of base stations 300.

[0421] 31 and 32 are diagrams illustrating another example of communication processing in the communication phase according to an embodiment of the present disclosure.

[0422] When the UE 100 starts moving, it communicates with the base station 300 included in the set 10 according to its own location.

[0423] 31, for example, the UE 100 is located near the base station 300 included in the set 10_2. In this case, the UE 100 communicates with the base station 300 included in the set 10_2.

[0424] For example, the UE 100 communicates with the base station 300_B3 to satisfy a first communication requirement (step S83), the UE 100 communicates with the base station 300_B5 to satisfy a second communication requirement (step S84), and the UE 100 communicates with the base station 300_B6 to satisfy a third communication requirement (step S85).

[0425] It should be noted that the base station 300_7 is a spare base station 300, and in Fig. 31 is not in communication with the UE 100. The base station 300_7 may, for example, communicate with another UE 100 (not shown).

[0426] 32 , when the UE 100 moves, the UE 100 is no longer able to perform communication that satisfies the desired communication requirements. Therefore, the UE 100 performs handover to a base station 300 included in the next set 10 before the UE 100 is no longer able to perform communication that satisfies the desired communication requirements.

[0427] For example, the server device 200 calculates the scheduled time of handover of the base station 300_B5 from the movement route P1 and movement speed of the UE 100. For example, the server device 200 sets the scheduled time of handover as the scheduled time of arrival of the UE 100 at the generation point used to generate each set 10. The generation point will be described later with reference to FIG. 35 .

[0428] The server device 200 specifies the calculated scheduled time and notifies the base station 300 at the handover destination (and / or handover source) via the 5G Core 400.

[0429] When the scheduled time for handover arrives (or when the UE 100 reaches the generation point), the handover source base station 300 performs handover to the handover destination base station 300 .

[0430] In the example of Figure 32, when the scheduled time for handover arrives, base station 300_5 hands over to base station 300_B4 to which the second communication requirements have been assigned, and UE 100 communicates with base station 300_B4 in a manner that satisfies the second communication requirements (step S86).

[0431] Similarly, handover from the base station 300_B6 to the base station 300_7 is performed.

[0432] For example, when the scheduled time for handover arrives, the base station 300_B6 hands over to the base station 300_B7 to which the third communication requirement has been assigned, and the UE 100 communicates with the base station 300_B7 in a manner that satisfies the third communication requirement (step S87).

[0433] The base station 300_B7 is included in the set 10_2 as a spare base station 300. Therefore, the base station 300_B7, for example, disconnects (stops) communication with another UE 100 (not shown) with which it is communicating, and communicates with the UE 100.

[0434] In this way, even if the base station 300 is the same, if it belongs to different sets 10, different communication requirements (or spare roles) may be assigned to each set 10.

[0435] The handover process performed here is the same as the handover process described using FIG. 19 and the like.

[0436] Furthermore, when it is determined that desired communication requirements cannot be met due to deterioration of communication quality caused by movement, handover of the base station 300 may be performed.

[0437] For example, when a handover is performed due to deterioration of communication quality caused by movement or the like, if communication that satisfies desired communication requirements cannot be performed with the handover destination base station 300, the UE 100 may perform a handover to a spare base station 300. Alternatively, in this case, the UE 100 may perform a handover to a base station 300 of another set 10.

[0438] Whether to perform handover to a spare base station 300 or to a base station 300 in another (next) set 10 can be determined based on, for example, the distance between the UE 100 and the base station 300 to which the UE 100 is to be handed over.

[0439] Furthermore, when the UE 100 reaches a location where handover is scheduled to be performed (for example, a generation point) before the scheduled time of handover, the UE 100 may request the base station 300 to perform handover via the server device 200. Alternatively, the server device 200 or the base station 300 may determine handover based on the current location of the UE 100.

[0440] It is also possible that the UE 100 arrives at the planned point where the handover is to be performed (for example, the generation point) after the planned time of the handover, that is, the UE 100 does not arrive at the planned point at the planned time of the handover.

[0441] In this case, the UE 100 may request the base station 300 not to perform handover at the scheduled time of handover. The UE 100 may request handover when it reaches a scheduled point where handover is to be performed (e.g., a generation point). Alternatively, the server device 200 or the base station 300 may determine handover based on the current location of the UE 100.

[0442] The scheduled time of handover may be calculated by the UE 100 or the base station 300 .

[0443] 33 to 37 are diagrams illustrating an example of a method for determining set 10 according to an embodiment of the present disclosure. As illustrated in Fig. 33, a method for determining set 10 when UE 100 moves along movement path P1 in an area where base stations 300_1 to 300_11 are located will be described here.

[0444] When the UE 100 determines the movement route P1, the UE 100 notifies the server device 200 of the notification information including information related to the movement route P1.

[0445] First, the server device 200 specifies the starting point of the travel route P1 and requests the 5G Core 400 to reserve the base station 300 for each communication requirement and spare base station.

[0446] The 5G Core 400 reserves the base station 300 whose distance from the starting point is equal to or less than a certain value, and notifies the server device 200 of the reservation result. At this time, the 5G Core 400 may notify the server device 200 of information on the coverage C of the reserved base station 300.

[0447] 34, the server device 200 creates a set 10 including a base station 300 to which the communication requirements desired by the UE 100 are assigned and a spare base station 300 as the set 10 at the starting point. In the example of FIG. 34, the server device 200 creates a set 10_1 including base stations 300_1 to 300_4 as the set 10 at the starting point of the movement route P1.

[0448] Next, the server device 200 determines a point (hereinafter also simply referred to as a generation point) for generating the next set 10 according to the coverage C of the base stations 300 included in the set 10_1 at the start point. For example, the server device 200 determines the intersection of the intersection of the coverage C of the base stations 300 included in the set 10_1 at the start point and the travel route P1 as the generation point for the next set 10.

[0449] 35, the server device 200 calculates the intersection of the coverages C1 to C4 of the base stations 300_1 to 300_4 (the shaded area in FIG. 35). The server device 200 sets the intersection S1 of the calculated intersection and the travel route P1 as the generation point.

[0450] 36, the server device 200 creates a set 10_2 including a base station 300 to which the communication requirements desired by the UE 100 are assigned and a spare base station 300 as a set 10 at a generation point S1. In the example of FIG. 36, the server device 200 creates a set 10_2 including base stations 300_3 to 300_6 as the set 10 of base stations 300 at a generation point S1 of a movement route P1.

[0451] By repeating the processes shown in FIGS. 35 and 36 up to the end point of the travel route P1, the server device 200 generates a set 10 of a plurality of base stations 300 according to the travel route P1.

[0452] 37, the server device 200 determines four sets 10_1 to 10_4 along the travel route P1. Set 10_3 includes, for example, base stations 300_5 to 300_8. Set 10_4 includes, for example, base stations 300_7 to 300_10.

[0453] In this way, the server device 200 determines in advance a plurality of sets 10 of base stations 300 to which roles (for example, communication requirements or spare) are assigned along the movement route P1 of the UE 100. This allows the UE 100 to smoothly perform handover to a base station 300 that satisfies the communication requirements according to the current location after movement, and enables stable communication that satisfies the desired communication requirements.

[0454] In the above-described embodiment, the 5G Core 400, more specifically, the SMO 310 that receives a request from the 5G Core 400, reserves the base station 300 according to the distance from the specified position, but the method of reserving the base station 300 is not limited to this.

[0455] For example, the SMO 310 may reserve a base station 300 having a certain level of communication quality or higher at the designated location. The SMO 310 may also preferentially reserve a base station 300 having a small number of users in its coverage area. Alternatively, the SMO 310 may preferentially reserve a base station 300 whose utilization rate is expected to be low at the time when the UE 100 communicates at the designated location.

[0456] As described above, in the communication system according to this embodiment, UE 100 transmits to server device 200, in accordance with user instructions, information regarding the communication requirements to be secured, terminal identification information, usage location and / or travel route, and at least one of the available communication carriers.

[0457] The server device 200 determines the 5G Core 400 to which the request is to be transmitted, based on the information acquired from the UE 100. The server device 200 transmits a request to the 5G Core 400 that has determined the reservation of the base station 300 for each communication requirement.

[0458] The 5G Core 400, more specifically, the SMO 310 connected to the 5G Core 400, searches for a base station 300 located near the usage location and reserves the use of the base station 300.

[0459] The SMO 310 uses RIC to optimize the network parameters (RAN parameters) of the RAN according to the communication requirements that are to be guaranteed (desired) for the reserved base station 300 .

[0460] The UE 100 connects to a different base station 300 for each communication requirement, and performs communication that satisfies the communication requirement.

[0461] When communication satisfying the communication requirements cannot be performed with the currently connected base station 300, the UE 100 continues communication satisfying the communication requirements by handing over to the spare base station 300. The spare base station 300 replicates the network parameters of the currently connected base station 300 by high-speed RAN network parameter control using RIC, and starts communication with the UE 100.

[0462] When changing the communication requirements, the UE 100 requests the change from the server apparatus 200. The base station 300 in communication with the UE 100 changes the parameters of the RAN in accordance with the request from the server apparatus 200.

[0463] Furthermore, when the UE 100 moves, it moves to a destination while transferring between a plurality of sets 10 .

[0464] This allows a user using UE 100 to perform work that requires communication that satisfies communication requirements at the location where UE 100 is used, or to move around while performing work.

[0465] In this way, the communication system according to the present embodiment creates in advance a set 10 of base stations 300 including spare base stations. In the communication system, for example, in an emergency such as a deterioration in communication quality, the spare base station 300 communicates with the UE 100 in place of the base station 300 that can no longer satisfy the communication requirements, thereby fulfilling the role of the base station 300 to which the communication requirements have been assigned.

[0466] In addition, the communication system can use RIC to change the RAN parameters of reserved base stations 300, thereby optimizing communication parameters that are generally difficult to control or dynamically change in network slices.

[0467] These communication parameters (e.g., RAN parameters) include a UL / DL ratio for each slot, a frequency band to be used, transmission power, etc. For example, these communication parameters (e.g., RAN parameters) include an MCS value, parameters related to antenna control such as a beamforming direction, a scheduling algorithm, a retransmission control algorithm, a reordering timer, and a discard timer.

[0468] As a result, the UE 100 can perform communication by using one or more base stations 300 in which RAN parameters are optimized for desired communication requirements, for each communication requirement. As a result, the UE 100 can perform communication that simultaneously satisfies one or more communication requirements more stably.

[0469] <<4. Other Embodiments>> The processing according to each of the above-described embodiments may be implemented in various different forms other than the above-described embodiments.

[0470] (Type of Base Station) The above-described base station 300 may be a fixed base station, or may be a mobile base station such as a satellite station or a High Altitude Platform Station (HAPS).

[0471] For example, when using the communication system of the present disclosure in an area where there are few fixed base stations, including a mobile base station in the base station 300 to be reserved allows the UE 100 to more reliably perform stable communication that meets the desired communication requirements.

[0472] Examples of places where there are few fixed base stations include mountainous areas, ocean areas, and remote islands.

[0473] For example, the server device 200 may combine fixed base stations and mobile base stations to determine the set 10 of base stations 300. The server device 200 may also determine the set 10 of base stations 300 by prioritizing either fixed base stations or mobile base stations.

[0474] The server device 200 may also prioritize either a fixed base station or a mobile base station as the base station 300 to which communication requirements are assigned. The server device 200 may also prioritize either a fixed base station or a mobile base station as the spare base station 300.

[0475] For example, the SMO 310 may periodically repeat the process of acquiring RU location information (see FIG. 10) to track the movement of the mobile base station. Also, the SMO 310 may periodically repeat the process of steps S205 to S207 of the communication process in the allocation phase of FIG.

[0476] This allows the SMO 310 to track the movement of the mobile base station and reserve an appropriate base station 300. When the base station 300 to be reserved is updated by this process, the SMO 310 can notify the server device 200 via the 5G Core 400 of the update of the reserved base station 300.

[0477] The server device 200 may refer to the travel route (e.g., a sea route) of the mobile base station to determine the set 10 of base stations 300. Alternatively, the SMO 310 may refer to the travel route of the mobile base station to determine the base station 300 to be reserved.

[0478] Alternatively, the server device 200 may request the mobile base station to change the moving route. For example, the server device 200 may request the mobile base station to accompany the movement of the UE 100.

[0479] The server device 200 determines a point where there are few fixed base stations visible from the UE 100, based on the movement information and geographic information of the UE 100. The server device 200 may request the mobile base station to move to the determined point. For example, the server device 200 may request the mobile base station to move to the vicinity of the determined point at the time when the UE 100 moves to the determined point.

[0480] Alternatively, if there is no base station 300 available for reservation, i.e., if all reservations have failed, the server device 200 may request the mobile base station to change the route, which allows the server device 200 to more reliably reserve the base station 300.

[0481] Although the server device 200 has been described as requesting the mobile base station to change the route, the request to the mobile base station is not limited to a route change. For example, the server device 200 may request the mobile base station to change the direction of the beamforming of the mobile base station in addition to or in addition to the route change. For example, the server device 200 requests the mobile base station to point a beam in the direction where the UE 100 is located.

[0482] In this way, by reserving the base stations 300 including the mobile base stations, the server device 200 can more reliably provide the UE 100 with communication that satisfies the desired communication requirements.

[0483] (Proposal of Movement Route) In the above-described embodiment, the server device 200 determines at least one set 10 of base stations 300 according to the movement route P1 acquired from the UE 100 .

[0484] The server device 200 may propose to the UE 100 a travel route that can more stably ensure the desired communication requirements. The UE 100 presents the proposed travel route to the user by, for example, displaying the acquired travel route on a display device. At this time, the UE 100 may present to the user a travel route that includes information on the communication requirements.

[0485] Fig. 38 is a diagram showing an example of a travel route proposed by the server device 200 according to another embodiment of the present disclosure. In Fig. 38, the same components as those in Fig. 30 are denoted by the same reference numerals, and description thereof will be omitted.

[0486] For example, after determining the set 10_1 to 10_3 of the base stations 300, the server device 200 searches for a travel route P2 that can more stably guarantee the communication requirements while performing communication using the set 10_1 to 10_3. The server device 200 notifies the UE 100 of the travel route P2 as a result of the search.

[0487] Alternatively, for example, the server device 200 requests candidate base stations 300 that can ensure desired communication requirements from the SMO 310 via the 5G Core 400. The server device 200 searches for a travel route that can more stably ensure the communication requirements from the acquired candidate base stations 300. The server device 200 notifies the UE 100 of the search result.

[0488] For example, there may be a case where the desired communication requirements cannot be satisfied by the travel route notified by the UE 100. In such a case, the server device 200 may search for a travel route that can satisfy the communication requirements.

[0489] The server device 200 may newly search for a plurality of movement routes and notify the UE 100 of the search results.

[0490] In addition, the server device 200 may obtain information on the starting point (departure point) and end point (destination) from the UE 100 instead of the travel route, and search for a travel route that can satisfy the communication requirements based on this information on the starting point and end point and information on the communication requirements.

[0491] The server device 200 may notify the UE 100 of information such as the travel time when using the travel route and the communication requirements that can be satisfied, together with the travel route, as accompanying information of the travel route.

[0492] For example, when the UE 100 determines an actual movement route (hereinafter also referred to as a final route) based on the movement route acquired from the server device 200, the UE 100 notifies the determined final route to the server device 200. For example, the server device 200 determines a set 10 of base stations 300 based on the final route.

[0493] Furthermore, in addition to the movement route (or the start point and the end point), the UE 100 may notify the server device 200 of a request regarding movement. Examples of the request regarding movement include priorities such as time priority or distance priority, and whether or not a mobile base station is to be used.

[0494] The server device 200 searches for a travel route that satisfies the communication requirements based on the associated information, and notifies the UE 100 of the search result.

[0495] Alternatively, instead of or in addition to the movement route, the server apparatus 200 may notify the UE 100 of area information relating to an area in which the communication requirements can be ensured.

[0496] For example, the server device 200 may calculate a probability that the communication requirements can be guaranteed, and notify the UE 100 of a heat map indicating the probability as area information. The server device 200 may create area information for each time, for example.

[0497] Furthermore, the server apparatus 200 may include a moving route of the UE 100 that has moved in the past while requesting similar communication requirements in the area information and notify the UE 100. At this time, the server apparatus 200 may notify the UE 100 of the past moving route of the UE 100 together with information on the communication quality at that time.

[0498] (Multiple spare base stations 300) In the above-described embodiment, the server device 200 includes one spare base station 300 in the set 10 of base stations 300, but the number of spare base stations 300 is not limited to one and may be two or more.

[0499] Fig. 39 is a diagram illustrating an example of a communication system according to another embodiment of the present disclosure. Components that are not necessary for the explanation are omitted from Fig. 39. Components that are the same as those in Fig. 30 are denoted by the same reference numerals, and explanations thereof will be omitted.

[0500] 39 , the server device 200 generates a set 10_5 of base stations 300 including base stations 300_B3, 300_B5, and 300_B6 to which communication requirements have been assigned, and spare base stations 300_7 and 300_9. In this manner, the server device 200 can set a plurality of spare base stations 300.

[0501] In FIG. 39, each of base stations 300_B3, 300_B5, and 300_B6 is performing communication with UE 100 that satisfies different communication requirements.

[0502] Here, for example, it is assumed that the UE 100 determines to switch one of the base stations 300_B3, 300_B5, and 300_B6 to the spare base station 300.

[0503] In this case, UE 100 may predict the communication quality of each spare base station 300_7, 300_9 when switching, for example, at the time when it decides to switch or a few seconds later, and select the spare base station 300 to switch to based on the prediction result.

[0504] For example, the UE 100 may perform a health check on the spare base stations 300_7 and 300_9, and select a spare base station 300 to switch to depending on the result of the health check.

[0505] The UE 100 can acquire radio information of the spare base stations 300_7 and 300_9 during a health check, for example, and predict the communication quality of the spare base stations 300_7 and 300_9 based on the acquired radio information.

[0506] The UE 100 may be equipped with, for example, a predictor (not shown) that predicts the communication quality of the backup base stations 300_7 and 300_9. The UE 100 uses, for example, the predictor to predict the communication quality of the backup base stations 300_7 and 300_9 at the time of switching.

[0507] In addition, UE 100 may use this predictor to predict the communication conditions (e.g., communication quality) of a base station 300 (e.g., base stations 300_B3, 300_B5, 300_B6) with which it is currently communicating after a predetermined period of time (e.g., several seconds, etc.).

[0508] Based on the prediction result, the UE 100 determines whether the communication requirements can be satisfied by communication with the base station 300 with which the UE 100 is currently communicating, in other words, whether to perform handover to the spare base station 300 .

[0509] Here, it is assumed that the UE 100 determines whether to hand over to the backup base station 300. However, as described above, the base station 300 currently in communication may determine whether to hand over.

[0510] In this case, the base station 300 may predict the communication quality of the backup base stations 300_7 and 300_9 in the case of switching, similarly to the UE 100, and determine the backup base station 300 to switch to depending on the prediction result.

[0511] Furthermore, base station 300 may predict the communication quality between UE 100 and base station 300, similarly to UE 100, and determine whether the communication requirements can be satisfied.

[0512] The base station 300 may predict these communication qualities using a predictor (not shown).

[0513] Alternatively, the base station 300 may predict the communication quality between the UE 100 and the spare base stations 300_7 and 300_9, and notify the UE 100. Based on the notification, the UE 100 may determine, for example, whether to perform handover or which spare base station 300 to determine as the handover destination.

[0514] Furthermore, it is assumed that the communication performance (e.g., communication quality) of the base station 300 that was originally used is recovered while the UE 100 is communicating with the backup base station 300. In other words, it is assumed that the handover source base station 300 is now able to perform communication that satisfies desired communication requirements while the UE 100 is using the backup base station 300 that is the handover destination.

[0515] In this case, the UE 100 may continue communication with the spare base station 300, or may resume communication with the handover source base station 300. When resuming communication with the handover source base station 300, the UE 100, for example, stops using the spare base station 300, performs handover again, and resumes communication with the base station 300 to which the desired communication requirements have been assigned.

[0516] In this way, by having the server device 200 prepare multiple spare base stations 300, the UE 100 can continue communication that satisfies the desired communication requirements by using the spare base station 300 with better communication quality.

[0517] Furthermore, even if it is determined that communication requirements cannot be met through communication with multiple base stations 300, UE 100 can stably continue multiple communications that meet the communication requirements by switching communication to multiple spare base stations 300.

[0518] (Switching to a base station other than the spare base station 300) In the above-described embodiment, the UE 100 switches communication to the spare base station 300 when the communication requirements cannot be satisfied, but the base station 300 to which the UE 100 switches communication is not limited to the spare base station 300. For example, the UE 100 may switch communication that cannot satisfy the communication requirements to a base station 300 to which other communication requirements are assigned.

[0519] Fig. 40 is a diagram showing an example of communication switching according to another embodiment of the present disclosure. Note that the same components as those in Fig. 30 are denoted by the same reference numerals, and description thereof will be omitted.

[0520] 40, it is assumed that UE 100 is communicating with base station 300_B3 in a manner that satisfies a first communication requirement, and with base station 300_B5 in a manner that satisfies a second communication requirement. Furthermore, it is assumed that UE 100 is communicating with base station 300_B6 in a manner that satisfies a third communication requirement. Furthermore, base station 300_B7 is a backup base station 300.

[0521] For example, when it is determined that the first communication requirement cannot be satisfied in communication with the base station 300_B3, the UE 100 may switch communication to the base station 300 having the highest communication quality among the set 10 of base stations 300. At this time, the UE 100 may stop communication related to other communication requirements and perform only communication that satisfies the first communication requirement.

[0522] In the example of FIG. 40, the UE 100 stops communication with the base stations 300_B3, 300_B5, and 300_B7, and performs communication with the base station 300_B6 that satisfies the first communication requirement.

[0523] In this case, the base station 300_B6 replicates the parameters (for example, RAN parameters) set in the base station 300_B3, performs handover, and starts communication with the UE 100.

[0524] In this way, by stopping communication for other communication requirements and continuing communication for the first communication requirement, UE 100 can make maximum use of available resources to communicate for the first communication requirement.

[0525] Here, it is assumed that the UE 100 stops the communication of the other communication requirements, but the communication of the other communication requirements does not have to be stopped.

[0526] For example, in FIG. 40, the UE 100 may continue the communication that satisfies the second communication requirement with the base station 300_B5, and switch the communication that satisfies the third communication requirement to the backup base station 300_B7.

[0527] For example, the UE 100 may determine, according to the importance (or priority) of the communication requirement, whether to switch communication including the base station 300 to which the communication requirement is assigned. Alternatively, the UE 100 may determine, according to the importance (or priority) of the communication requirement, whether to stop communication of other communication requirements.

[0528] For example, when moving through an area where there are few available base stations 300, such as inside a tunnel or deep in the mountains, UE 100 may stop communication for other communication requirements in order to ensure that communication requirements of high importance are met.

[0529] Here, it is assumed that the UE 100 stops communication for the other communication requirements except for one communication requirement, but the number of communication requirements for which communication is not stopped is not limited to one. For example, the UE 100 may guarantee communication that satisfies two or more communication requirements and stop communication that satisfies the other communication requirements. Which communication requirements are guaranteed and how many of them are stopped, in other words, which communication requirements are stopped and how many of them are stopped, can be determined depending on the importance of the communication requirements, the communication quality of the base station 300, etc.

[0530] Furthermore, the UE 100 may calculate in advance when it is highly likely that the communication requirements will not be guaranteed along the movement route P1, and notify the user of the calculated timing. The UE 100 may notify the user of information regarding the communication requirements that may not be guaranteed and the time (or area) when the requirements may not be guaranteed.

[0531] Furthermore, when there is a possibility that all communication requirements cannot be guaranteed, the UE 100 may notify the user to that effect. This notification is preferably performed before the start of movement.

[0532] Furthermore, when notifying the user of the possibility that the communication requirements may not be guaranteed, the UE 100 may present information on new communication requirements that can be guaranteed to the user. When the user requests communication that satisfies the new communication requirements, the UE 100 may request the server device 200 to reserve the base station 300 that allocates the new communication requirements.

[0533] Here, the determination, selection, and the like that are supposed to be performed by the UE 100 may be performed by the server device 200 or the base station 300 .

[0534] (Multiple Carriers) Furthermore, the server device 200 may determine the set 10 of base stations 300 across multiple communication carriers.

[0535] 41 is a diagram illustrating another example of a communication system according to another embodiment of the present disclosure. Note that the same components as those in FIG. 3 are denoted by the same reference numerals, and descriptions thereof will be omitted.

[0536] The communication system shown in FIG. 41 includes a UE 100, a Server 200, a plurality of cellular networks N_1, N_2, . . . , and a plurality of AFs 500_1, 500_2, .

[0537] The cellular networks N_1, N_2, and so on are networks provided by different communication carriers. The cellular network N_1 includes a RAN 300_1 and a 5G Core 400_1. The cellular network N_2 includes a RAN 300_2 and a 5G Core 400_2.

[0538] The AFs 500_1, 500_2, ... are provided to correspond to the cellular networks N_1, N_2, ..., respectively. The AFs 500_1, 500_2, ... connect the corresponding cellular networks N_1, N_2, ... and the Server 200.

[0539] The UE 100 connects to cellular networks provided by a plurality of communication carriers, for example, by using SIMs of different communication carriers for each communication module.

[0540] As described above, the server device 200 reserves the base stations 300 for each communication requirement and generates the set 10 of the base stations 300. At this time, the server device 200 may generate the set 10 of the base stations 300 including the base stations 300 of different communication carriers.

[0541] Furthermore, the server device 200 may assign the same communication requirement to base stations 300 that belong to different communication carriers. That is, the set 10 of base stations 300 may include multiple base stations 300 to which the same communication requirement is assigned. However, these base stations 300 belong to different communication carriers.

[0542] Alternatively, the server device 200 may generate a set 10 of multiple base stations 300 for each communication carrier. This set 10 of multiple base stations 300 differs from the sets 10_1 to 10_4 of multiple base stations 300 when the UE 100 moves in that the sets 10 of multiple base stations 300 are in the same usage location.

[0543] In this case, the server device 200 assigns the same communication requirements to a plurality of base stations 300. However, these base stations 300 belong to different communication carriers and belong to different sets 10 of base stations 300.

[0544] The UE 100 switches (hands over) the base station 300 depending on the location of use, communication conditions, etc. Depending on the reserved base station 300, the UE 100 switches the communication carrier to switch the base station 300. That is, the communication carrier of the handover destination base station 300 is different from the communication carrier of the handover source base station 300.

[0545] In addition, if there are multiple base stations 300 assigned the same communication requirements, UE 100 may switch communication to a base station 300 belonging to the communication carrier with which it is currently communicating, or may switch to a base station 300 with higher communication quality.

[0546] (Notification of RAN parameters) In the above-described embodiment, the UE 100 notifies the server apparatus 200 of desired communication requirements, but the information that the UE 100 notifies the server apparatus 200 of is not limited to the communication requirements. For example, the UE 100 may notify the server apparatus 200 of desired RAN parameters.

[0547] UE 100 may notify server device 200 of at least one RAN parameter, such as an MCS value, an UL / DL slot allocation ratio, a beamforming direction, a scheduling algorithm, a retransmission control algorithm, a reordering timer, and a discard timer.

[0548] The UE 100 calculates the RAN parameters from the desired communication requirements based on, for example, the setting file, calculation formula, correspondence table, etc. of the control policy described above.

[0549] For example, the UE 100 notifies the calculated RAN parameters to the server apparatus 200. The server apparatus 200 requests the SMO 310 to reserve the base station 300 by specifying the RAN parameters in place of the communication requirements.

[0550] The SMO 310 omits conversion of the control policy and notifies the RAN parameters to the NearRT-RIC 320. The NearRT-RIC 320 omits calculation of the RAN parameters and notifies the RU 350 of the specified RAN parameters.

[0551] The server device 200 or the base station 300 may verify whether the RAN parameters notified from the UE 100 have normal values, i.e., whether they are abnormal values. If the RAN parameters have normal values, the server device 200 or the base station 300 reserves the base station 300, and if the RAN parameters have abnormal values, the server device 200 or the base station 300 does not reserve the base station 300.

[0552] If the RAN parameter has an abnormal value, the server device 200 or the base station 300 determines that the reservation of the base station 300 has failed.

[0553] Alternatively, if the RAN parameters have abnormal values, the server device 200 or the base station 300 may convert the RAN parameters to normal values ​​and make a reservation for the base station 300. In this case, the server device 200 or the base station 300 may notify the UE 100 of the converted RAN parameters together with the fact that the reservation has been successful.

[0554] The UE 100 may notify the server apparatus 200 of the RAN parameter change request, for example, via a GUI screen or a CUI of the UE 100. Alternatively, the UE 100 may notify the server apparatus 200 of the RAN parameter change request when a user operates hardware such as a button or a switch.

[0555] In addition, the UE 100 may notify the communication requirements in addition to the RAN parameters to the server apparatus 200. The server apparatus 200 notifies the base station 300 (specifically, the SMO 310) of the RAN parameters and the communication requirements via the 5G Core 400.

[0556] The base station 300 determines the control policy and / or RAN parameters to be actually set based on the notified communication requirements and RAN parameters, and notifies the UE 100 of the set control policy and / or RAN parameters.

[0557] Furthermore, the UE 100 may notify the server apparatus 200 of a control policy instead of or in addition to the RAN parameters.

[0558] In this case, the NearRT-RIC 320 calculates the RAN parameters from the control policy notified by the UE 100 .

[0559] In addition, the UE 100 may notify the RAN parameter change request directly to the 5G Core 400 via the AF 500, instead of the server device 200.

[0560] Furthermore, the server apparatus 200 may calculate a control policy and / or a RAN parameter based on the communication requirements notified by the UE 100 .

[0561] Alternatively, the server device 200 may set communication requirements (or control policies / RAN parameters) to be guaranteed in communication with the UE 100 based on information regarding applications that the UE 100 can use and the purpose of these applications.

[0562] The server device 200 collects, for example, information about applications that can be used by the UE 100, usage, etc. from the UE 100, a communication partner of the UE 100, etc. The server device 200 sets communication requirements (or control policies / RAN parameters) based on the collected information and reserves the base station 300.

[0563] The collection of information about the application and its use may be performed by the server apparatus 200 while the UE 100 is actually performing communication. The server apparatus 200 collects information about the application used by the UE 100 and its use, for example, periodically.

[0564] For example, the server device 200 may notify the base station 300 with which it is communicating to change the communication requirements (or control policy / RAN parameters) of the base station 300 based on the collected information.

[0565] The base station 300 (specifically the SMO 310) may use the RIC to dynamically change RAN parameters.

[0566] For example, the base station 300 can dynamically change the UL / DL slot allocation ratio based on information about the application, the usage, and the like.

[0567] Alternatively, the base station 300 may set the MCS to a specific value depending on information about the application, the purpose, etc. For example, when an application that transmits video is used, the base station 300 sets the MCS to a higher value and increases the value of forward error correction (FEC). On the other hand, when an application that requires stable transmission of low-resolution video is used, the base station 300 sets the MCS to a lower value.

[0568] Alternatively, the server device 200 may collect location information and surrounding geographic information of the UE 100. The server device 200 may notify the base station 300 (more specifically, the SMO 310) of the collected information, for example.

[0569] The base station 300 performs optimal beamforming taking reflected waves into consideration, for example, based on the location information of the UE 100 and surrounding geographic information.

[0570] In this way, by setting the RAN parameters according to the information collected by the server apparatus 200, the UE 100 can perform communication that satisfies communication requirements according to the application to be used.

[0571] Although it is assumed here that UE 100 notifies server apparatus 200 of desired RAN parameters, the apparatus that notifies server apparatus 200 of desired RAN parameters is not limited to UE 100. For example, base station 300 (more specifically, for example, CU 330 / DU 340) may notify server apparatus 200 of desired RAN parameters for each UE 100.

[0572] For example, the base station 300 may notify the server device 200 of RAN parameters that satisfy desired communication requirements, depending on the communication status with the UE 100. Alternatively, the base station 300 may notify the server device 200 of the communication status with each UE 100, for each UE 100.

[0573] (Other) In the above-described embodiment, the server device 200 requests the reservation of the base station 300 for each communication requirement. That is, the server device 200 requests the reservation of the base station 300 by specifying one communication requirement. However, the number of communication requirements specified by the server device 200 at the time of the request is not limited to one, and may be multiple.

[0574] For example, the server device 200 may request reservation of the base station 300 by specifying all of one or more communication requirements notified by the UE 100. In this case, the server device 200 requests reservation of the set 10 of the base stations 300. In response to the request, the base station 300 (specifically, the SMO 310) reserves the base station 300 and the spare base station 300 to which each of the specified communication requirements is assigned.

[0575] In this way, the base stations 300 may determine the set 10 of base stations 300 .

[0576] The control device that controls the UE 100, the server device 200, the base station 300, or the 5G Core 400 of this embodiment may be realized by a dedicated computer system or a general-purpose computer system.

[0577] For example, a communication program for executing the above-described operations is stored in a computer-readable recording medium such as an optical disk, a semiconductor memory, a magnetic tape, or a flexible disk and distributed. Then, for example, the program is installed in a computer and the above-described processing is executed to configure a control device. In this case, the control device may be a device (e.g., a personal computer) external to the UE 100, the server device 200, the base station 300, or the 5G Core 400. Furthermore, the control device may be a device internal to the UE 100, the server device 200, the base station 300, or the 5G Core 400.

[0578] 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.

[0579] 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.

[0580] Furthermore, the components of each device shown in the figure are conceptual functional units and do not necessarily have to be physically configured as shown. 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 the devices can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc. Note that this distribution and integration configuration may also be performed dynamically.

[0581] 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 flowcharts of the above-described embodiments can be changed as appropriate.

[0582] 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).

[0583] 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. Therefore, multiple devices housed in separate housings and connected via a network, and a single device in which multiple modules are housed in a single housing, are both systems.

[0584] 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.

[0585] <<5. Conclusion>> As described above, according to the present embodiment, the UE 100 notifies the server device 200 and the connected 5G Core 400 of information regarding at least one of communication requirements to be secured, terminal identification information, location information, and available communication carriers. The UE 100 notifies this information and checks whether the request is satisfied.

[0586] If the request is satisfied, the 5G Core 400 (more specifically, the SMO 310) reserves the base station 300 in which the network parameters of the RAN (for example, the RAN parameters) are optimized for each communication requirement to be guaranteed, based on the location information. For example, the 5G Core 400 arranges the base station 300 in which the RAN parameters are optimized near the usage location of the UE 100.

[0587] During communication, the UE 100 determines, for each piece of data (packet) to be transmitted, communication requirements required for transmitting this data, and performs communication by switching the base station 300 to be connected to for each communication requirement.

[0588] As a result, the UE 100 can perform communication that satisfies communication requirements in each communication with one or more base stations.

[0589] 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.

[0590] Furthermore, the effects of the embodiments described in this specification are merely examples and are not limiting, and other effects may also be obtained.

[0591] The present technology may also be configured as follows. (1) A terminal device including a control unit that notifies an information processing device of information including requirement information related to one or more communication requirements before starting communication, selects the communication requirement, communicates with a base station to which the selected communication requirement is assigned from one or more base stations assigned to each of the one or more communication requirements, and, if it is determined that the selected communication requirement cannot be satisfied in the communication with the base station, performs handover from the base station to another base station that satisfies the selected communication requirement. (2) The terminal device described in (1), in which network parameters according to the selected communication requirement are set in the base station. (3) The terminal device described in (1) or (2), in which the requirement information includes at least one of quality information related to communication quality, slice information related to a network slice, bandwidth information related to a bandwidth used for the communication, and delay information related to an allowable delay time. (4) The terminal device described in any one of (1) to (3), in which the information notified to the information processing device includes at least one of identification information for identifying the terminal device, location information related to the location of the terminal device, and operator information related to a communication operator that the terminal device can use. (5) The terminal device according to (4), wherein the identification information includes information on at least one of an IMSI (International Mobile Subscriber Identity), an IMEI (International Mobile Equipment Identity), a GUTI (Globally Unique Temporary Identifier), an MSISDN (Mobile Station International Subscriber Directory Number), and an IP address assigned to the terminal device. (6) The terminal device according to (4) or (5), wherein the location information includes at least one of information on the location where the terminal device performs the communication and information on a movement route of the terminal device.(7) The terminal device according to any one of (4) to (6), wherein the operator information includes at least one of an International Mobile Subscriber Identity (IMSI), a Mobile Country Code (MCC), and information identifying the telecommunications carrier. (8) The terminal device according to any one of (1) to (7), wherein the control unit performs the handover from the base station to the other base station when the terminal device moves to a scheduled position and / or when a scheduled time has passed. (9) The terminal device according to any one of (1) to (7), wherein the control unit performs the handover to the other base station in accordance with an instruction from the base station. (10) The terminal device according to any one of (1) to (7), wherein the control unit requests the handover from the other base station via the information processing device. (11) The terminal device according to (9) or (10), wherein the other base station is the base station to which the communication requirements have not been assigned, and to which the communication requirements are assigned when a request to perform the handover is made. (12) The terminal device according to (11), wherein, when communication with the base station that satisfies the communication requirements can be performed, the control unit performs the handover from the other base station to the base station. (13) The terminal device according to any one of (9) to (12), wherein the other base station stops communication with another terminal device different from the terminal device that is performing the handover, and performs the handover. (14) The terminal device according to (9) or (10), wherein the other base station is the base station to which the communication requirements that are different from the selected communication requirements are assigned. (15) The terminal device according to any one of (1) to (8), wherein the base station to which the communication requirements are assigned is updated according to time and / or the location of the terminal device, and the other base station is the updated base station to which the selected communication requirements are assigned. (16) The terminal device according to any one of (1) to (15), wherein the control unit acquires map information including information on the communication requirements from the information processing device. (17) The terminal device according to (16), wherein the control unit causes a display device to display the map information.(18) The terminal device according to (16) or (17), wherein the map information includes at least one of route information regarding a route that can ensure the communication requirements and area information indicating the communication requirements for each area. (19) The terminal device according to any one of (1) to (18), wherein the other base station is a different telecommunications carrier from the base station. (20) An information processing device comprising: a control unit that acquires information including requirement information regarding one or more communication requirements from the terminal device, selects a base station to which to assign the communication requirement for each of the one or more communication requirements, and, when it is determined that the communication requirement selected by the terminal device cannot be satisfied in communication between the base station and the terminal device, instructs the other base station to perform handover from the base station communicating with the terminal device to another base station that satisfies the selected communication requirement. (21) A base station comprising: a storage unit that stores, in accordance with a request from an information processing device, information regarding base stations to which one or more communication requirements have been assigned, the communication requirements; and a control unit that performs communication with a terminal device to which one of the one or more communication requirements has been assigned and that satisfies the assigned communication requirements, and when it is determined that the assigned communication requirement cannot be satisfied in the communication with the terminal device, performs handover to another base station that satisfies the assigned communication requirements, in accordance with the information stored in the storage unit. (22) A communication method comprising: before starting communication, notifying an information processing device of information including requirement information regarding one or more communication requirements, selecting the communication requirement, performing communication with the base station to which the selected communication requirement has been assigned, from among one or more base stations assigned for each of the one or more communication requirements, and when it is determined that the selected communication requirement cannot be satisfied in the communication with the base station, performing handover from the base station to another base station that satisfies the selected communication requirement.(23) A communication method comprising: acquiring information including requirement information regarding one or more communication requirements from a terminal device; selecting a base station to which to assign the communication requirements for each of the one or more communication requirements; and, when it is determined that the communication requirement selected by the terminal device cannot be satisfied in communication between the base station and the terminal device, instructing the other base station to perform a handover from the base station currently communicating with the terminal device to another base station that satisfies the selected communication requirements. (24) A communication method comprising: storing, in a storage unit, information regarding a base station to which one or more communication requirements are assigned, for each of the one or more communication requirements, in accordance with a request from an information processing device; performing communication with a terminal device to which one of the one or more communication requirements is assigned and that satisfies the assigned communication requirement; and, when it is determined that the assigned communication requirement cannot be satisfied in the communication with the terminal device, performing a handover to another base station that satisfies the assigned communication requirement, in accordance with the information stored in the storage unit.

[0592] 100 Terminal device 110, 210 Communication unit 120 Tethering unit 130 Application execution unit 140, 220 Storage unit 150, 230 Control unit 200 Server device 300 Base station 310 SMO 330 CU 340 DU 350 RU 400 5G Core

Claims

1. A terminal device comprising: a control unit that, before starting communication, notifies an information processing device of information including requirement information regarding one or more communication requirements; selects the communication requirements; communicates with a base station to which the selected communication requirements are assigned, from one or more base stations assigned for each of the one or more communication requirements; and, if it is determined that the selected communication requirements cannot be satisfied in the communication with the base station, performs handover from the base station to another base station that satisfies the selected communication requirements.

2. The terminal device according to claim 1, wherein network parameters according to the selected communication requirements are set in the base station.

3. The terminal device of claim 1, wherein the requirement information includes at least one of quality information regarding communication quality, slice information regarding network slices, bandwidth information regarding the bandwidth used for the communication, and delay information regarding the allowable delay time.

4. The terminal device according to claim 1, wherein the information notified to the information processing device includes at least one of identification information for identifying the terminal device, location information regarding the location of the terminal device, and operator information regarding a telecommunications operator that can be used by the terminal device.

5. The terminal device according to claim 4, wherein the location information includes at least one of information about the location where the terminal device performs the communication and information about the movement route of the terminal device.

6. The terminal device according to claim 4, wherein the operator information includes at least one of an International Mobile Subscriber Identity (IMSI), a Mobile Country Code (MCC), and information identifying the telecommunications operator.

7. The terminal device according to claim 1, wherein the control unit performs the handover from the base station to the other base station when the terminal device moves to a scheduled position and / or when a scheduled time has passed.

8. The terminal device according to claim 1, wherein the control unit performs the handover to the other base station in accordance with an instruction from the base station.

9. The terminal device according to claim 1, wherein the control unit requests the handover from the other base station via the information processing device.

10. The terminal device according to claim 8, wherein the other base station is a base station to which the communication requirements have not been assigned, and to which the communication requirements are assigned when a request to perform the handover is made.

11. The terminal device according to claim 10, wherein, when the communication with the base station that satisfies the communication requirements can be performed, the control unit performs the handover from the other base station to the base station.

12. The terminal device according to claim 8, wherein the other base station stops communication between the terminal device performing the handover and another terminal device different from the terminal device performing the handover, and then performs the handover.

13. The terminal device according to claim 8, wherein the other base station is the base station to which the communication requirement different from the selected communication requirement is assigned.

14. The terminal device according to claim 1, wherein the base station to which the communication requirements are assigned is updated according to the time and / or the location of the terminal device, and the other base station is the updated base station to which the selected communication requirements are assigned.

15. The terminal device according to claim 1, wherein the control unit acquires map information including information relating to the communication requirements from the information processing device.

16. The terminal device according to claim 15, wherein the control unit causes a display device to display the map information.

17. The terminal device according to claim 15, wherein the map information includes at least one of route information relating to a route that can ensure the communication requirements, and area information indicating the communication requirements for each area.

18. The terminal device according to claim 1, wherein the other base station is of a different carrier than the base station.

19. An information processing device comprising: a control unit that acquires information including requirement information regarding one or more communication requirements from a terminal device; selects a base station to which to assign the communication requirement for each of the one or more communication requirements; and, if it is determined that the communication requirement selected by the terminal device cannot be satisfied in communication between the base station and the terminal device, instructs the other base station to perform a handover from the base station communicating with the terminal device to another base station that satisfies the selected communication requirement.

20. A communication method including: notifying an information processing device of information including requirement information regarding one or more communication requirements before starting communication; selecting the communication requirements; communicating with a base station to which the selected communication requirements are assigned, from one or more base stations assigned for each of the one or more communication requirements; and, if it is determined that the selected communication requirements cannot be satisfied in the communication with the base station, performing handover from the base station to another base station that satisfies the selected communication requirements.

Images