Communication system, communication contract management device, communication terminal, and program

Abstract

A communication system according to the present invention comprises a communication contract management device and a communication terminal, wherein the communication contract management device has: a calculation unit that calculates, for each of a plurality of base stations, a contract period which is a valid period of a contract for connecting to said base station on the basis of a history including an interval between a time when a contract for connecting any one of communication terminals to said base station was established in response to a connection request from the communication terminal and a time when a contract for connecting the communication terminal to a next base station was established and an elapsed time from the connection request for which said base station was selected as the connection destination until the contract was established; a selection unit that selects, before the communication terminal connected to the first base station switches the connection destination, a second base station as a switching destination from a set of base stations to which the communication terminal can connect; and a notification unit that notifies the communication terminal connected to the first base station of information indicating the second base station and the contract time calculated by the calculation unit, and the communication terminal connected to the first base station improves the ease of use thereof by switching the connection destination after the elapse of the contract period with the second base station since the connection to the second base station was extablished.

Description

Communication system, communication contract management device, communication terminal, and program

[0001] The present invention relates to a communication system, a communication contract management device, a communication terminal, and a program.

[0002] Communication terminals such as smartphones can ensure wireless communication quality at or above a certain level by performing handover in accordance with movement. In existing cellular systems and systems implemented based on IEEE 802.11, handover with few instantaneous interruptions is realized.

[0003] On the other hand, a technology is being studied that allows a communication terminal to utilize various base stations in an autonomous distributed manner without requiring a central control station, by appropriately establishing connection contracts between the user of the communication terminal and a plurality of base station providers using a blockchain network (Non-Patent Document 1). In the technology of Non-Patent Document 1, after the wireless communication quality, usage time, and usage fee of a base station and the payment capability of the communication terminal side are confirmed, a transaction for a connection contract is issued, and the transaction is transmitted to the blockchain network. After receiving the transaction, the blockchain network selects one base station as the connection destination of the communication terminal and authenticates the contract. Thereafter, the communication terminal becomes able to communicate with the Internet via the base station.

[0004] "Architecture Implementation and Feasibility Study on Blockchain-based Wireless Access Sharing", 2024 IEEE 99th Vehicular Technology Conference

[0005] In general, in a blockchain network, when a certain number of transactions are accumulated, a block including the transactions is generated. Further, after a sufficient number of blocks are additionally generated, each transaction (connection contract) is authenticated. For transactions whose processing timing and issuance timing overlap, a certain period of delay occurs until the processing corresponding to the request is completed. The finer the block granularity (the number of transactions included in one block), the higher the security that is ensured, but the greater the delay in response to requests.

[0006] If the technology described in Non-Patent Document 1 is adopted, based on the characteristics of such a blockchain network, when a communication terminal performs a handover, there is a possibility that a certain amount of delay may occur due to the processing of the contract transaction with the base station to which the handover is being performed. As a result, communication may be interrupted during communication by the communication terminal, potentially reducing the convenience of the communication terminal.

[0007] This invention has been made in view of the above points, and aims to improve the convenience of communication terminals.

[0008] To solve the above problems, in a communication system including a communication contract management device and a communication terminal, the communication contract management device has a calculation unit that calculates a contract time, which is the valid period of the contract for connecting to a base station, based on a history of the time when a contract for connecting to a base station is concluded in response to a connection request from any communication terminal, the time when a contract for connecting the communication terminal to the next base station is concluded, and the elapsed time from the connection request to which the base station became the connection destination until the contract is concluded; a selection unit configured to select a second base station as the switching destination from a set of base stations that the communication terminal can connect to before the communication terminal connected to the first base station switches its connection destination; and a notification unit configured to notify the communication terminal connected to the first base station of information indicating the second base station and the contract time calculated by the calculation unit, wherein the communication terminal connected to the first base station is configured to switch its connection destination after the contract time of the second base station has elapsed since connecting to the second base station.

[0009] This can improve the convenience of communication devices.

[0010] This figure shows an example of the configuration of a wireless communication system in the first embodiment. This figure shows an example of the hardware configuration of each node constituting the blockchain NW10 in the first embodiment. This figure shows an example of the functional configuration of a wireless communication system in the first embodiment. This is a sequence diagram illustrating an example of a processing procedure performed in the wireless communication system in the first embodiment. This figure shows an example of a connection history. This figure shows an example of authentication delay information.

[0011] In each embodiment described below, wireless base stations (BS20), such as wireless LAN base stations or cellular base stations, owned by various network providers (hereinafter referred to as "NW providers") issue transactions related to contracts with communication terminals (UE30) used by users to the blockchain network, and contracts and authentication (contract formation) are executed using the blockchain network. In this embodiment, "contract" refers to an agreement between the BS20 and the UE30 that enables communication under conditions such as wireless communication quality, price, and period. Authentication refers to verifying that there are no problems with the contract.

[0012] The identity verification of UE30 requesting the contract and BS20 issuing the transaction is achieved by comparing their respective digital signatures (hereinafter simply referred to as "signatures") with information pre-registered on the blockchain network (verifying each signature with the pre-registered public keys of UE30 and BS20).

[0013] After verifying that transactions have not been tampered with on the blockchain network, contracts and authentication are carried out in accordance with various consensus algorithms such as PoW and PoA.

[0014] Furthermore, since the blockchain network cannot obtain information such as the amount of data transmitted or the UE's connected BS, it is assumed that UE30 will pay a fixed usage fee (hereinafter referred to as "contract fee") to each contracted BS20, regardless of whether a connection is established or not, based on the contracted time. Contracted time refers, for example, to the period during which communication between UE30 and BS20 related to a single contract is valid.

[0015] The embodiments will be described below with reference to the drawings.

[0016] Figure 1 shows an example of the configuration of a wireless communication system in the first embodiment. In Figure 1, the wireless communication system includes one or more UEs 30, one or more BSs 20, one or more communication networks 50, and a blockchain network 10, etc. Each UE 30 can communicate with any of the BSs 20. Each BSs 20 can communicate with the blockchain network 10.

[0017] UE30 refers to communication devices used by users, such as smartphones, tablet devices, and PCs (Personal Computers). When UE30 connects to an uncontracted BS20, it uses the blockchain NW10 to conclude a contract. Upon conclusion of the contract, the UE30 (user) pays a contract fee to the network provider related to BS20 (hereinafter referred to as the "NW provider").

[0018] BS20 is an example of a communication device that functions as a wireless base station, such as a wireless LAN base station or a cellular base station. BS20 provides wireless communication to UE30 in accordance with the established contract. The network provider for BS20 receives a contract fee. One network provider may manage multiple BS20s. There may be multiple network providers.

[0019] Communication NW50 is a communication network that connects each BS20 to the blockchain NW10. Communication NW50 may include a wired section or a wireless section.

[0020] Blockchain NW10 is a blockchain network composed of multiple nodes that record transactions in a ledger in blockchain format. Blockchain NW10 authenticates transactions by verifying the signatures of BS20 and UE30 attached to the transaction, and adds the new block to the ledger. The block to be added is determined by various consensus algorithms such as PoW and PoA. Each BS20 also functions as a node in Blockchain NW10.

[0021] The communication procedure during connection, as shown in (1) to (4) in Figure 1, is as follows. Note that this communication procedure may be the same as that described in Non-Patent Document 1.

[0022] (1) UE30 temporarily connects to the BS20 with the highest signal strength among the BS20s that observed the radio signal, and transmits a contract request bearing its signature to that BS20 via this temporary connection. At this time, UE30 sends to the BS20 a list of the SSID and received power of the BS20 that observed the radio signal (hereinafter referred to as the "BS list"). A temporary connection means a connection of radio communication permitted for the purpose of requesting a contract. The BS2 list of a certain UE30 means a list of BS20s that are candidates for connection to that UE30.

[0023] (2) Upon receiving the contract request, BS20 adds its signature and issues a transaction containing the BS list on the blockchain.

[0024] (3) Blockchain NW10 authenticates the transaction by verifying the signatures of BS20 and UE30, and notifies BS20 of the authentication result. Blockchain NW10 also determines the appropriate BS20 as the connection destination from the BS list included in the transaction. Blockchain NW10 stores a BS list for each UE30 and records information in the BS list indicating which BS20 the UE30 is connected to. Blockchain NW10 disseminates the transaction, which includes information indicating the BS20 that the UE30 is connected to and the details of the contract between the two, to each node of Blockchain NW10 and each BS20. The transaction is also disseminated to BS20, which is one of the nodes of Blockchain NW10, and the transaction is recorded in the ledger of that BS20. The contract details include contract time and fees. When the operations shown in (1) to (4) of Figure 1 are carried out and a certain amount of contract experience is accumulated, the contract time may be calculated by the calculation method of the contract time calculation unit 13 described later.

[0025] (4) BS20 and UE30, which have been determined as connection destinations, will perform the contract in accordance with the transaction. In other words, BS20, which has been determined as a connection destination, will enable communication with UE30 for the duration of the contract period.

[0026] Figure 2 shows an example of the hardware configuration of each node constituting the blockchain NW10 in the first embodiment. Each node has a drive device 100, an auxiliary storage device 102, a memory device 103, a processor 104, and an interface device 105, etc., which are interconnected by bus B.

[0027] The program that enables processing at each node is provided on a recording medium 101 such as a CD-ROM. When the recording medium 101 containing the program is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. However, the program does not necessarily have to be installed from the recording medium 101; it may also be downloaded from another computer via a network. The auxiliary storage device 102 stores the installed program as well as necessary files and data.

[0028] The memory device 103 reads and stores a program from the auxiliary storage device 102 when a program startup command is received. The processor 104 is either a CPU or a GPU (Graphics Processing Unit), or both a CPU and a GPU, and executes functions related to each node according to the program stored in the memory device 103. The interface device 105 is used as an interface for connecting to the network.

[0029] Furthermore, UE30 and BS20, etc., may also have the hardware configuration shown in Figure 2.

[0030] Figure 3 shows an example of the functional configuration of a wireless communication system in the first embodiment. In Figure 3, each node of the blockchain network 10 has an average usage time calculation unit 11, an average authentication delay time calculation unit 12, a contract time calculation unit 13, a selection unit 14, a generation unit 15, and a notification unit 16. Each of these units is realized by processing that one or more programs installed on each node of the blockchain network 10 have the processor 104 execute. Each node of the blockchain network 10 also utilizes a connection history storage unit 121, an authentication delay storage unit 122, and a transaction storage unit 123. Each of these storage units can be realized using, for example, an auxiliary storage device 102.

[0031] The connection history storage unit 121 stores the connection history (contract history) of each UE30 to the BS20. The connection history is information that shows, for each BS20 that each UE30 has connected to (contracted with) in the past, the timing of the connection to that BS20 (timing of the contract with that BS20) and the order of connection (contract order).

[0032] The average usage time calculation unit 11, the average authentication delay time calculation unit 12, and the contract time calculation unit 13 constitute an example of a calculation unit that calculates the contract time, which is the valid period of the contract for connecting to a BS20, based on the history of the time when a contract for connecting to a BS20 in response to a connection request from any UE 30 is concluded, the time when a contract for connecting to the next BS20 is concluded by that UE 30, and the elapsed time from when the BS20 receives a connection request from any UE 30 to which the contract is concluded.

[0033] Specifically, the average usage time calculation unit 11 calculates the average usage time for each of the multiple BS20s, which is the average of the interval between the time a contract to connect to the BS20 in response to a connection request from any of the UE30s is concluded and the time a contract to connect to the next BS20 of the UE30 is concluded. The time each contract is concluded can be identified by referring to the connection history storage unit 121.

[0034] The average authentication delay time calculation unit 12 refers to the authentication delay storage unit 122 and calculates the average authentication delay time for each of the multiple BS20, which is the average elapsed time from when the blockchain NW10 receives a connection request from any UE30 until the contract for that connection request is concluded. The authentication delay storage unit 122 stores for each BS20 information indicating the timing when the connection request was received and information indicating the timing when the contract for that connection request was concluded.

[0035] The contract time calculation unit 13 calculates the contract time for each of the multiple BS20s by subtracting the average authentication delay time of the BS20 from the average usage time of the BS20. By doing so, the average authentication delay time (i.e., the time required for processing such as issuing contract transactions) can be excluded from the contract time, and excessive contract fees can be avoided for the communication usage by the UE30 users.

[0036] The selection unit 14 selects the BS20 to be switched (hereinafter referred to as the "HO destination") from the set of BS20s to which the UE 30 connected to any of the BS20s can connect, before the UE 30 switches its connection destination (i.e., before the handover (hereinafter referred to as "HO") is performed). Here, the set of BS20s to which the UE 30 can connect is the set of BS20s related to the BS list notified by the UE 30.

[0037] The generation unit 15 generates information indicating that a contract has been concluded for the UE 30 to connect to the HO destination BS20 selected by the selection unit 14, before the UE 30 switches to the destination BS20. In this embodiment, the generation of this information is performed by issuing a transaction indicating that a contract for connecting to the HO destination BS20 has been concluded for the target UE 30. The transaction includes, for example, the contract time and contract fee as part of the contract. The contract time is the contract time calculated by the contract time calculation unit 13 for the HO destination BS20. As mentioned above, the contract fee is assumed to be a fixed amount, not a usage-based fee for communication volume. However, the contract fee can also be varied according to the contract time. The issued transaction is stored in the transaction storage unit 123 and is also disseminated to each BS20, which is also a node of the blockchain NW10.

[0038] The notification unit 16 executes a process to notify the target UE 30 of the information indicating the HO destination selected by the selection unit 14 and the contract time calculated by the contract time calculation unit 13.

[0039] Furthermore, the transaction storage unit 123 and the connection history storage unit 121 can be implemented using the distributed ledger of the blockchain NW10. The connection history may also be extracted from the transaction history. In other words, the transaction storage unit 123 may also function as the connection history storage unit 121.

[0040] BS20 has a BS communication unit 21. The BS communication unit 21 is implemented by a process that one or more programs installed on BS20 cause the processor of BS20 to execute. BS20 also utilizes a transaction storage unit 201. The transaction storage unit 201 can be implemented, for example, using an auxiliary storage device of BS20.

[0041] The BS communication unit 21 controls the communication functions as a radio base station. For example, the BS communication unit 21 relays a request from the UE 30 to the blockchain NW 10 to the blockchain NW 10, and relays notifications and the like from the blockchain NW 10 to the UE 30 to the UE 30. The BS communication unit 21 also executes processing for enabling the UE 30 that has a contract with the BS 20 to communicate with the Internet or the like.

[0042] The transaction storage unit 201 stores transactions issued in the blockchain NW 10. Note that the transaction storage unit 201 can be implemented using the distributed ledger of the blockchain NW 10.

[0043] The UE 30 includes a radio communication quality monitoring unit 31, a connection request unit 32, a handover control unit 33, and a UE communication unit 34. These units are implemented by processing that one or more programs installed in the UE 30 cause the processor of the UE 30 to execute.

[0044] The radio communication quality monitoring unit 31 monitors the quality of the communication (radio communication quality) while the UE 30 is connected to any of the BSs 20 and performing communication.

[0045] The connection request unit 32 transmits a connection request to the blockchain NW 10 at a predetermined timing before the UE 30 performs HO. In the present embodiment, the timing at which the radio communication quality state monitored by the radio communication quality monitoring unit 31 reaches a predetermined state corresponds to the aforementioned predetermined timing. The predetermined state refers to a state that is not to the extent that communication is impossible (to the extent that HO, which is the switching of the connection-destination BS 20 based on the radio communication quality, is performed), but the possibility of becoming unable to communicate within a certain period of time (the possibility that HO will be required) has increased. That is, the predetermined state refers to a state in which the state of the UE 30 is within a predetermined range from the state where the connection-destination base station is switched based on the radio communication quality. For example, a state in which the received power from the connected BS 20 has decreased by a threshold value α or more from the start of connection may be defined as the predetermined state.

[0046] The switching control unit 33 controls execution of HO (switching of the BS 20 that is the connection destination). For example, the switching control unit 33 executes HO at the timing when the contracted time of the relevant BS 20 elapses after connecting to the BS 20 that is the connection destination.

[0047] The UE communication unit 34 performs communication via the BS 20 that is the connection destination.

[0048] In the following, the processing procedure executed in the wireless communication system will be described. FIG. 4 is a sequence diagram for explaining an example of the processing procedure executed in the wireless communication system according to the first embodiment. In FIG. 4, it is assumed that the UE 30 is connected to the BS 20-1 through the processing procedures (1) to (4) described in FIG. 1. In FIG. 4, in this state, an example of the processing procedure executed to smoothly realize the switching (handover) of the BS 20 that is the connection destination of the UE 30 will be described. In the description of FIG. 4, strictly speaking, the processing executed by the blockchain NW 10 is executed by the nodes of the blockchain NW 10.

[0049] The radio communication quality monitoring unit 31 of the UE 30 (hereinafter referred to as "target UE 30") that is connected to the BS 20-1 monitors the radio communication quality of the communication of the UE 30 via the BS 20-1 (S101). When the radio communication quality monitoring unit 31 detects that the radio communication quality has reached a predetermined state (Yes in S101), the connection request unit 32 transmits a connection request including a BS list to the blockchain NW 10 via the connected BS 20-1 (S102, S103). As described above, the BS list is a list of the SSIDs, received power, and the like of the BSs 20 for which the target UE 30 has observed radio signals at the current point in time. The predetermined state is also as described above. Therefore, the connection request is transmitted before the target UE 30 requires HO.

[0050] When the connection request is received in the blockchain NW 10, the average usage time calculation unit 11 refers to the connection history stored in the connection history storage unit 121 for each BS 20 related to the BS list included in the connection request, and calculates the average usage time (S104).

[0051] Figure 5 shows an example of a connection history. As shown in Figure 5, the connection history includes the UE_ID, contract date and time, and BS_ID for each previously concluded contract. The UE_ID is the identification information of the UE30 that is connecting in the contract. The contract date and time is the date and time when the contract was concluded (when the contract transaction was issued). The contract date and time allows for the identification of the order of the contracts (connections). Note that in Figure 5, only the time is shown for convenience. The BS_ID is the identification information of the BS20 that is connecting in the contract. Note that (1) to (3) in Figure 5 show the connection history for each UE30 (i.e., for each UE_ID).

[0052] The average usage time calculation unit 11 calculates the interval between the contract time for each BS20 in the connection history for each UE30 (Figure 5, (1) to (3)) and the next record, including the BS_ID of the BS20. This interval is considered to be the usage time of the BS20. This is because a BS20 contracted by a certain UE30 at a certain point in time is considered to have been used (connected) by that UE30 until that UE30 enters into the next contract.

[0053] The average usage time calculation unit 11 calculates the average value of the intervals calculated for each BS20. This average value is the average usage time.

[0054] Figure 5 shows the interval between contract dates and times for each of the UE30s corresponding to (1) to (3), where the BS_ID is "bs01" and the next record. In the order of (1), (2), and (3), the intervals are 10 minutes, 20 minutes, and 5 minutes. In this case, the average usage time for BS20 with BS_ID "bs01" is (10 + 20 + 5) ÷ 3.

[0055] In step S104, the average usage time is calculated for each BS20 included in the BS list.

[0056] Next, the average authentication delay time calculation unit 12 calculates the average authentication delay time for each BS20 by referring to the information stored in the authentication delay storage unit 122 (hereinafter referred to as "authentication delay information") for each BS20 related to the BS list included in the received connection request (S105).

[0057] Figure 6 shows an example of authentication delay information. Figure 6 shows authentication delay information for a particular BS20. As shown in Figure 6, the authentication delay information stores the connection request ID, connection request reception time, and connection request authentication time for each past connection request (connection request from UE30) to which the BS20 was the destination.

[0058] The connection request ID is the identification information for each connection request. The connection request reception time is the time when the blockchain NW10 receives the connection request. For example, when a connection request is received in step S104, a new record is added to the authentication delay information for the source of the connection request (BS20-1 in the example in Figure 4), and the time at that point is recorded in the record as the connection request reception time. The connection request authentication time is the time when the contract is authenticated in response to the connection request and the transaction issuance process is completed.

[0059] The average authentication delay time calculation unit 12 calculates the elapsed time from the time the connection request is received to the time the connection request is authenticated (i.e., the authentication time of the connection request minus the time the connection request is received) for each connection request ID as the authentication delay time, and calculates the average value of these values ​​as the average authentication delay time for the BS20. In the example in Figure 6, the authentication delay times for each connection request ID are 30 seconds and 60 seconds, so the average authentication delay time is 45 seconds.

[0060] In step S105, the average authentication delay time is calculated for each BS20 included in the BS list.

[0061] Next, the contract time calculation unit 13 calculates the contract time for each BS20 included in the BS list by subtracting the average authentication time of the BS20 from the average usage time of the BS20 (S106). For example, if the authentication delay information in Figure 6 is the authentication delay information for BS20 whose BS_ID is "bs01" (i.e., the BS20 whose average usage time is shown in Figure 5), the contract time (seconds) for that BS20 can be calculated as {(10 + 20 + 5) ÷ 3} × 60 - 45.

[0062] In step S106, the contract time is calculated for each BS20 included in the BS list.

[0063] Next, the selection unit 14 selects one of the BS20s included in the BS list as the next connection destination (i.e., HO destination) BS20 for the target UE30 (S107). For example, the BS20 that is estimated to be most advantageous for the wireless communication quality of the target UE30 is selected as the HO destination by a known method based on the current capacity of each BS20 for the UE30, the received power, etc.

[0064] Next, the generation unit 15 authenticates the contract for the target UE 30 to connect to the HO destination BS 20 selected by the selection unit 14, and if the authentication is successful, it issues a transaction indicating the conclusion of the contract (S108). This transaction includes the contract details (contract time and contract fee calculated for the HO destination in step S106, etc.) and is recorded in the transaction storage unit 123. This transaction is also disseminated to each BS 20 and recorded in the transaction storage unit 201 of each BS 20. Note that the authentication of the contract is performed based on, for example, whether or not the UE 30 has the ability to pay, based on information stored in advance for each UE 30. If block generation or the like is performed at this stage, it may take several tens of seconds to complete step S108.

[0065] Thus, in this embodiment, a contract is concluded with BS20, the recipient of the HO, before the target UE30 executes the HO, and a transaction for that contract is issued. Upon issuance of the transaction, the target UE30 incurs an obligation to pay the contract fee.

[0066] Next, the notification unit 16 notifies (transmits) the target UE 30 via BS20-1, to which the target UE 30 is connected, of the information indicating the HO destination selected by the selection unit 14 (hereinafter referred to as "HO destination information") and the contract time calculated for the HO destination in step S106 (S109, S110). At this timing, the notification unit 16 may record the current time in the connection request authentication time of the authentication delay information record corresponding to the connection request received in step S104.

[0067] Next, the connection request unit 32 of the target UE 30 receives the HO destination information and contract time (S111). Subsequently, the switching control unit 33 waits for the "contract time of BS20-1" to elapse since the connection to the current destination BS20-1 (S112). Also, while the "contract time of BS20-1" has not elapsed (No in S112), the wireless communication quality monitoring unit 31 monitors whether the wireless communication quality of the target UE 30 has fallen below a value that prevents communication (S113).

[0068] Here, the "contract time of BS20-1" referenced in step S112 is not the contract time of the HO destination received in the immediately preceding step S111, but the contract time notified by blockchain NW10 at the time before the target UE30 connects to BS20-1. This timing is timing (3) in Figure 1. If the target UE30 has made an HO to BS20-1 from another BS20, then this timing is the timing of the execution of the previous step S111. The "communication failure value" refers to the value at which the UE30 determines that a switch of the connected BS20 is necessary. The "communication failure value" includes a value corresponding to the state of "unable to communicate stably," and does not necessarily mean only a state where communication is impossible. The "communication failure value" is thought to be set to an appropriate value at the time, as it varies depending on the wireless method used by the target UE30 and the surrounding environment. For example, -70 dBm for wireless LAN and -110 dBm for 5G NR are examples of values ​​that would result in "communication failure."

[0069] If the "contract time for BS20-1" has elapsed (Yes in S112), or if the wireless communication quality monitoring unit 31 detects that the wireless communication quality of the target UE 30 has fallen below a value that prevents communication (Yes in S113), the switching control unit 33 starts HO. In other words, in this embodiment, HO is started even if the wireless communication quality has not fallen below a value that prevents communication, as long as the "contract time for BS20-1" has elapsed.

[0070] In step S114, the switching control unit 33 requests a connection to the HO destination (in this case, BS20-2) indicated by the HO destination information received in step S111. The BS communication unit 21 of BS20-2 responds to this request and determines whether the target UE 30 has already entered into a contract with BS20-2 (S115). This determination can be made based on whether the transaction corresponding to the contract (hereinafter referred to as the "target transaction") is stored in the transaction storage unit 201. In this case, since the target transaction is recorded in the transaction storage unit 201 in step S108 (i.e., the relevant contract has been made) (Yes in S116), the BS communication unit 21 notifies the blockchain NW 10 of the connection of the target UE 30 (S117). The selection unit 14 of the blockchain NW 10 responds to the notification from BS20-2 and adds a record indicating that the target UE 30 has connected to BS20-2 to the connection history storage unit 121 (S118). In this case, the contract date and time of the record should simply record the date and time when the transaction in question was issued.

[0071] Next, the BS communication unit 21 of BS20-2 provides the target UE 30 with communication based on the contract details of the target transaction (S119). As a result, the connection between the target UE 30 and BS20-1 is disconnected, and the UE communication unit 34 of the target UE 30 can communicate to the Internet, etc., via BS20-2 during the contract time of the target transaction (i.e., the contract time of BS20-2). Steps S101 onwards are repeated for this communication as well, and once the contract time of BS20-2 has elapsed, the target UE 30 switches the connection destination.

[0072] If the target transaction is not stored in the transaction storage unit 201 of BS20-2 (No in S117), the contract will be executed according to the procedure described in Figure 1.

[0073] As described above, according to the first embodiment, a contract is concluded with the HO destination BS20 in advance before UE30 executes the HO. Therefore, processing by the blockchain NW10 in response to the connection request in step S114 is unnecessary, and UE30 can smoothly execute the HO based on the previously concluded contract.

[0074] However, because a contract with BS20-2 (the destination) is established during the contract hours of the currently connected BS20-1, there is a possibility of an overlap in the contract hours of the two BS20 channels. The longer this overlap period, the more unnecessary contract fees the user will have to pay, increasing the user's burden.

[0075] Therefore, in this embodiment, a UE 30 connected to a certain BS20 switches its connection destination (performs an HO) after the contract time for that BS20 has elapsed. Here, the contract time for a certain BS20 is the time obtained by subtracting the processing time (authentication delay time) by the blockchain NW10 from the empirical value of the elapsed time between when a UE 30 that previously connected to that BS20 made a contract with that BS20 and when it made a contract with another BS20. In other words, the contract time for a certain BS20 is an approximation of the time that a UE 30 that previously used that BS20 actually used to communicate. By setting an HO trigger based on such a contract time, it is possible to forcibly execute an HO at a timing that the UE 30 is expected to perform based on empirical evidence, and the above-mentioned overlap period can be expected to be shortened. In the example in Figure 4, it is possible to increase the possibility that step S114 will be executed in a short period of time after the HO destination information is received in step S111.

[0076] As described above, according to this embodiment, even when a contract is made using the blockchain NW10, HO can be streamlined, and the increase in user burden for facilitating HO can be suppressed. Therefore, the convenience of communication terminals can be improved.

[0077] Next, a second embodiment will be described. The differences between the second embodiment and the first embodiment will be described. Points not specifically mentioned in the second embodiment may be the same as in the first embodiment.

[0078] In the second embodiment, the method by which the selection unit 14 selects the HO destination in step S107 of Figure 4 differs from that in the first embodiment. In the second embodiment, the selection unit 14 selects the HO destination based on the contract time of each BS20 included in the BS list.

[0079] Specifically, the selection unit 14 prioritizes selecting BS20 with relatively longer contract times from the BS list as HO destinations. For example, the selection unit 14 selects the BS20 with the longest contract time as the HO destination. Alternatively, the selection unit 14 selects a BS20 whose contract time is equal to or greater than a threshold as the HO destination. If there are multiple BS20s whose contract time is equal to or greater than a threshold, the selection unit 14 selects one BS20 from among the multiple BS20s whose contract time is equal to or greater than a threshold in the same manner as in the first embodiment. Note that the threshold can be specified by the UE 30. In this case, the connection request unit 32 of the UE 30 transmits a connection request including the BS list and the threshold in step S102.

[0080] As described above, according to the second embodiment, BS20, which has a relatively longer contract time, is preferentially selected as the host. As a result, the number of host events due to the expiration of the contract time can be suppressed. By suppressing the number of host events, the number of prior contracts with host parties can be reduced, thereby reducing the burden on the user.

[0081] In each of the above embodiments, the blockchain NW10 (each node) is an example of a communication contract management device.

[0082] The functions of the elements disclosed herein may be implemented using circuits or processing circuitry that include general-purpose processors, special-purpose processors, integrated circuits, ASICs (Application Specific Integrated Circuits), FPGAs (Field Programmable Gate Arrays), conventional circuits, and / or combinations thereof that are programmed using one or more programs stored in one or more memories, or otherwise configured to perform the disclosed functions. A processor is considered processing circuitry or circuitry because it includes transistors and other circuits. A processor may be a programmed processor that executes programs stored in memory. In this disclosure, a circuit, unit, or means is hardware that performs the enumerated functions, or hardware programmed to perform the enumerated functions. Hardware may be any hardware disclosed herein that is programmed or configured to perform the enumerated functions.

[0083] There is a memory for storing a computer program that includes computer instructions. These computer instructions provide logic and routines that enable hardware (e.g., processing circuitry or circuitry) to perform the methods disclosed herein. This computer program can be implemented in commonly known forms, such as computer-readable storage media, computer program products, memory devices, recording media such as CD-ROMs and DVDs, and / or memory in FPGAs and ASICs.

[0084] Although embodiments of the present invention have been described in detail above, the present invention is not limited to these specific embodiments, and various modifications and changes are possible within the scope of the gist of the present invention as described in the claims.

[0085] 10 Blockchain NW 11 Average Usage Time Calculation Unit 12 Average Authentication Delay Time Calculation Unit 13 Contract Time Calculation Unit 14 Selection Unit 15 Generation Unit 16 Notification Unit 20 BS 21 BS Communication Unit 30 UE 31 Wireless Communication Quality Monitoring Unit 32 Connection Request Unit 33 Switching Control Unit 34 UE Communication Unit 100 Drive Device 101 Recording Medium 102 Auxiliary Storage Device 103 Memory Device 104 Processor 105 Interface Device 121 Connection History Storage Unit 122 Authentication Delay Storage Unit 123 Transaction Storage Unit 201 Transaction Storage Unit B Bus

Claims

1. A communication system including a communication contract management device and a communication terminal, wherein the communication contract management device includes: a calculation unit configured to calculate a contract time, which is the validity period of a contract to connect to a base station, based on a history of the time at which a contract to connect to a base station is concluded in response to a connection request from any communication terminal, the time at which a contract to connect to the next base station is concluded for the communication terminal, and the elapsed time from the connection request to which the base station became the connection destination until the contract is concluded; a selection unit configured to select a second base station as the switching destination from a set of base stations to which the communication terminal can connect before the communication terminal connected to the first base station switches its connection destination; and a notification unit configured to notify the communication terminal connected to the first base station of information indicating the second base station and the contract time calculated by the calculation unit, wherein the communication terminal connected to the first base station is configured to switch its connection destination after the contract time of the second base station has elapsed since connecting to the second base station.

2. The communication system according to claim 1, wherein the calculation unit includes: an average usage time calculation unit configured to calculate, for each of the plurality of base stations, the average usage time which is the average interval between the time at which a contract to connect to the base station in response to the connection request is concluded and the time at which a contract to connect to another base station of the communication terminal is concluded; an average authentication delay time calculation unit configured to calculate, for each of the plurality of base stations, the average elapsed time from the connection request to which the base station is the connection destination until the contract is concluded; and a contract time calculation unit configured to calculate, for each of the plurality of base stations, the value obtained by subtracting the average authentication delay time from the average usage time as the contract time.

3. The communication system according to claim 2, characterized in that the selection unit is configured to select the second base station based on the average usage time of each of the base stations to which a communication terminal connected to the first base station can connect.

4. The communication system according to claim 3, characterized in that the selection unit is configured to preferentially select the base station having a relatively longer contract time as the second base station.

5. A communication contract management device comprising: a calculation unit configured to calculate a contract time, which is the validity period of a contract to connect to a base station, based on a history of the time at which a contract to connect to a base station is concluded in response to a connection request from any communication terminal, the time at which a contract is concluded for the communication terminal to connect to the next base station, and the elapsed time from the connection request to which the base station became the connection destination until the contract is concluded; a selection unit configured to select a second base station as the destination from a set of base stations to which a communication terminal can connect before the communication terminal connected to the first base station switches its connection destination; and a notification unit configured to notify the communication terminal connected to the first base station of information indicating the second base station and the contract time calculated by the calculation unit.

6. A communication terminal comprising: a connection request unit configured to receive the base station to which the connection will be switched and the contracted time of said base station before switching the base station to which the connection will be switched; and a switching control unit configured to switch the base station to which the connection will be switched after the contracted time has elapsed since the connection was switched to said base station.

7. A program characterized by causing a communication terminal to execute a connection request procedure that receives the base station to which the connection will be switched and the contracted time of said base station before switching the connection destination base station, and a switching control procedure that switches the connection destination base station after the contracted time has elapsed since the connection destination was switched to said base station.

Images