Communication system, communication contract management device, communication terminal, program, and contract time management method
Patent Information
- Application Number
- PCT/JP2025/015315
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-04-18
- Publication Date
- 2026-10-22
Smart Images
Figure JP2025015315_22102026_PF_FP_ABST
Abstract
Description
Communication system, communication contract management device, communication terminal, program, and contract time management method
[0001] The present invention relates to a communication system, a communication contract management device, a communication terminal, a program, and a contract time management method.
[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 under IEEE 802.11, handover with few instantaneous interruptions is achieved.
[0003] On the other hand, a technology is being studied that allows communication terminals to use various base stations in an autonomous decentralized manner without requiring a centralized control station, by allowing users of communication terminals and multiple base station providers to appropriately enter into connection contracts using a blockchain NW (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 on the communication terminal side are confirmed, a transaction for a connection contract is issued, and the transaction is transmitted to the blockchain NW. After receiving the transaction, the blockchain NW selects one base station as the connection destination of the communication terminal and authenticates the contract. Thereafter, the communication terminal can 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] Generally, in a blockchain network, when a certain number of transactions accumulate, a block containing those transactions is generated. Furthermore, after a sufficient number of additional blocks have been generated, authentication of each transaction (connection contract) is performed. For transactions where the timing of this processing and the timing of issuance overlap, a certain delay occurs before the processing requested is completed. The finer the block granularity (the number of transactions included in one block), the higher the security ensured, but the greater the delay in responding 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 includes a calculation unit configured to calculate a contract time, which is the valid period of the contract for the first communication terminal to connect to a base station, based on the wireless communication quality observed by the communication terminal at the time when any of the communication terminals connect and at the time when the communication terminal switches its connection destination, and the rate of change of wireless communication quality observed by the first communication terminal connected to the first base station; a selection unit configured to select a second base station to switch to from a set of base stations to which the first communication terminal can connect before the first communication terminal 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, and the first communication terminal 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 wireless communication quality history. This is a diagram illustrating a method for calculating estimated usage time. This figure shows an example of 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 estimated 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 causes the processor 104 to 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 estimated usage time calculation unit 11, the average authentication delay time calculation unit 12, and the contract time calculation unit 13 each constitute a calculation unit that calculates the contract time, which is the valid period of the contract for a UE 30 to connect to a BS20, based on the wireless communication quality observed by the UE 30 at the time when any of the UE 30 connects and at the time when the UE 30 switches its connection destination, and the rate of change in wireless communication quality observed by a UE 30 connected to a certain BS20.
[0033] Specifically, the estimated usage time calculation unit 11 calculates, for each of the multiple BS20s, the time required at the rate of change for the amount of change in wireless communication quality observed by the UE30 at the time when one of the UE30s connects and at the time when the UE30 switches the connection destination (hereinafter referred to as "estimated usage time"). Each time point 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 estimated 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, thereby preventing excessive contract fees from being charged to users of the UE30 for their communication usage.
[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 wireless base station. For example, the BS communication unit 21 relays requests from UE 30 to blockchain NW 10 to blockchain NW 10, and relays notifications from blockchain NW 10 to UE 30 to UE 30. The BS communication unit 21 also performs processing to enable the UE 30, which has a contract with the BS 20, to communicate with the internet, etc.
[0042] The transaction storage unit 201 stores transactions issued in the blockchain network 10. The transaction storage unit 201 can be implemented using the distributed ledger of the blockchain network 10.
[0043] The UE30 includes a wireless communication quality monitoring unit 31, a connection request unit 32, a switching control unit 33, and a UE communication unit 34. Each of these units is implemented by one or more programs installed on the UE30 causing the UE30's processor to execute processes. The UE30 also utilizes a wireless communication quality history storage unit 301. The wireless communication quality history storage unit 301 can be implemented, for example, using an auxiliary storage device of the UE30.
[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 one of the BSs 20 and performing communication. The radio communication quality monitoring unit 31 observes (measures) the received power from the BS 20 at a plurality of timings (for example, periodically) after the UE 30 connects to the BS 20, and records the received power in the radio communication quality history storage unit 301.
[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 predetermined timing. The predetermined state refers to a state that is not severe enough to disable communication (not severe enough to trigger HO, which is the switching of the connected BS 20 based on the radio communication quality), but has an increased possibility of losing communication within a certain period of time (an increased possibility that HO becomes necessary). That is, the predetermined state refers to a state where the state of the UE 30 is within a predetermined range from the state where the connected base station is to be switched based on the radio communication quality. For example, a state where 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 the execution of HO (switching of the connected BS 20). For example, the switching control unit 33 executes HO at the timing when the contracted time for the connected BS 20 elapses after connecting to the connected BS 20.
[0047] The UE communication unit 34 performs communication via the connected BS 20.
[0048] Hereinafter, processing procedures executed in a wireless communication system will be described. FIG. 4 is a sequence diagram for explaining an example of processing procedures 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 with reference to FIG. 1. FIG. 4 describes an example of processing procedures executed to smoothly realize switching (handover) of the connection destination BS 20 of the UE 30 in this state. In the description of FIG. 4, the processing executed by the blockchain NW 10 is strictly executed by the nodes of the blockchain NW 10.
[0049] The wireless communication quality monitoring unit 31 of the UE 30 connected to the BS 20-1 (hereinafter referred to as "target UE 30") monitors the wireless communication quality of the communication of the UE 30 via the BS 20-1, and records the wireless communication quality observed at a plurality of timings (hereinafter referred to as "wireless communication quality history") in the wireless communication quality history storage unit 301 (S101).
[0050] FIG. 5 is a diagram illustrating an example of the wireless communication quality history. As shown in FIG. 5, the wireless communication quality history includes time, BS_ID, received power, and the like for each observation of wireless communication quality. The time is the point in time when the wireless communication quality observation was performed. The BS_ID is identification information of the BS 20 that is the observation target of the wireless communication quality. In the example of FIG. 4, the identification information of the BS 20-1 to which the target UE 30 is connected is recorded as the BS_ID. The received power is the observed value of the wireless communication quality. In the present embodiment, received power is described as an example of wireless communication quality, but other wireless communication quality indicators such as throughput may be set as the observation target.
[0051] When the wireless communication quality monitoring unit 31 detects that the wireless communication quality has reached a predetermined state (Yes in S101), the wireless communication quality monitoring unit 31 calculates the rate of change in the wireless communication quality of BS20-1, and the connection request unit 32 sends a connection request including the BS list and the rate of change to the blockchain NW10 via the connected BS20-1 (S102, S103). The BS list is, as described above, a list of the SSIDs and received power of the BS20s whose wireless signals the target UE30 has observed at the present time. The rate of change in wireless communication quality is, for example, the rate of change (attenuation) of the wireless communication quality (received power) observed for BS20-1 from the time the target UE30 connected to BS20-1 until the present time. For example, the speed is calculated by, for instance, (received power at the last observation - received power at the first observation) ÷ (elapsed time from the first observation to the last observation). In this case, according to the example in Figure 5, the rate of change = (-70 - (-60)) ÷ 10 = -1 [dbm / min]. The predetermined conditions are as described above. Therefore, the connection request is transmitted before the target UE30 requires HO.
[0052] When a connection request is received in the blockchain NW10, the estimated usage time calculation unit 11 calculates the estimated usage time for each BS20 related to the BS list included in the connection request, based on the change rate included in the connection request and the connection history stored in the connection history storage unit 121 (S104).
[0053] Figure 7 shows an example of a connection history. As shown in Figure 7, the connection history includes the UE_ID, contract date and time, BS_ID, received power, and connected BS 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 7, only the time is shown for convenience. The BS_ID and received power are the BS_ID and received power of each BS20 belonging to the BS list included in the connection request that triggered the contract. The connected BS is the identification information of the BS20 selected as the connection destination in the contract.
[0054] Figure 6 is a diagram illustrating the method for calculating the estimated usage time. Here, we will focus on one BS20 and explain the method for calculating the estimated usage time of that BS20 (hereinafter referred to as "Target BS20").
[0055] First, the estimated usage time calculation unit 11 extracts from the connection history storage unit 121 all records (hereinafter referred to as "connection records") for when any UE 30 connects to the target BS20, and records (hereinafter referred to as "switching records") corresponding to the connection switching related to each connection record. A connection record is a record that includes the BS_ID of the target BS20 as the connecting BS. A switching record for a given connection record is the first record among the records after that connection record that includes the same UE_ID as that connection record, and that includes the BS_ID of a BS20 other than the target BS20 as the connecting BS.
[0056] Here, we assume that the BS_ID of the target BS20 is "bs01". In the table in (1) of Figure 6, the first row corresponds to the connection record, and the second row corresponds to the switching record. The connection record is the record when UE30, whose UE_ID is "ue01", connects to the target BS20, and the switching record is the record when UE30 connects to BS20, whose BS_ID is "bs03" (that is, the record when UE30 switches its connection destination from the target BS20 to the switching BS20).
[0057] Here, in the connection record, the received power corresponding to the target BS20 (bs01) corresponds to the received power observed by the UE30 (ue01) at the time of connection to the target BS20, and in the switching record, the received power corresponding to the target BS20 (bs01) corresponds to the received power observed by the UE30 (ue01) at the time of changing the connection destination from the target BS20 (HO). The estimated usage time calculation unit 11 calculates the amount of change (attenuation) of the received power of the target BS20 in the switching record corresponding to the connection record from the received power of the target BS20 in the connection record for each connection record. In Figure 6, for convenience, there is only one connection record, but if there are multiple connection records, the average value of the amount of change is calculated.
[0058] The estimated usage time calculation unit 11 calculates the estimated usage time by dividing the average value of the calculated change by the rate of change received in step S104. In other words, assuming that the received power from the target BS20 attenuates at the rate of change when the target UE30 is connected to the target BS20, the estimated time required from the time the target UE30 is connected to the target BS20 until the target UE30 performs HO is calculated as the estimated usage time. Figure 6(2) shows a diagram illustrating the process of calculating the estimated usage time by dividing the average value of the change by the rate of change. Specifically, in Figure 6(2), point p1 is plotted with an x-coordinate value of 0 and a y-coordinate value of -60 dBm (the average value of the received power of the target BS20 in the connection record) in a coordinate system where the x-axis is time and the y-axis is received power. The x-coordinate of the intersection point p2 of a line passing through point p1 with a slope equal to the rate of change and the line y = -67 dBm (the average value of the received power of BS20, the target of the switching record) is the estimated usage time.
[0059] In step S104, the estimated usage time is calculated for each BS20 included in the BS list.
[0060] 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).
[0061] Figure 8 shows an example of authentication delay information. Figure 8 shows authentication delay information for a particular BS20. As shown in Figure 8, 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.
[0062] 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.
[0063] 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 8, the authentication delay times for each connection request ID are 30 seconds and 60 seconds, so the average authentication delay time is 45 seconds.
[0064] In step S105, the average authentication delay time is calculated for each BS20 included in the BS list.
[0065] 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 estimated usage time of the BS20 (S106). For example, for a BS20 with an estimated usage time of 7 minutes and an average authentication delay time of 45 seconds, the contract time is calculated as 7 × 60 - 45 (seconds).
[0066] In step S106, the contract time is calculated for each BS20 included in the BS list.
[0067] 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.
[0068] 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.
[0069] 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.
[0070] 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.
[0071] 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).
[0072] 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."
[0073] 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.
[0074] 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 UE_ID, contract date and time, BS_ID, received power, and connected BS of the record should, in order, record the UE_ID of the target UE30, the date and time when the target transaction was issued, each BS_ID and each received power included in the BS list received in step S104, and the BS_ID of BS20-1.
[0075] 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 for 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 when the contract time of BS20-2 has elapsed, the target UE 30 switches its connection destination. The contract time is calculated based on the wireless communication quality observed by the UE 30 at the time when any UE 30 connects to BS20-2 and at the time when the UE 30 switches its connection destination, as well as the rate of change of wireless communication quality observed by the target UE 30, as described above.
[0076] 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.
[0077] 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.
[0078] However, because a contract with BS20-2 (the HO destination) is established during the contract time of the currently connected BS20-1, there is a possibility of an overlap in the contract times recorded in block 10 for the two BS20s before and after the connection switch. The longer this overlap period, the more the user will have to pay unnecessary contract fees (payment for duplicate billing), which will increase the user's burden.
[0079] 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.
[0080] 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.
[0081] 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.
[0082] 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.
[0083] 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.
[0084] 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.
[0085] In each of the above embodiments, the blockchain NW10 (each node) is an example of a communication contract management device.
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 10 Blockchain NW 11 Estimated 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 301 Wireless Communication Quality History 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 valid period of a contract for a first communication terminal to connect to a base station, based on the wireless communication quality observed by the communication terminal at the time when any of the communication terminals connect to a base station and at the time when the communication terminal switches its connection destination, and the rate of change of wireless communication quality observed by the first communication terminal connected to the first base station; a selection unit configured to select a second base station to switch to from a set of base stations to which the first communication terminal can connect, before the first communication terminal 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 first communication terminal 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 estimated usage time calculation unit configured to calculate, for each of the plurality of base stations, an estimated usage time which is the time required at the rate of change for the amount of change in received power observed by the communication terminal at the time when any of the communication terminals connect and at the time when the communication terminal switches connection destinations; an average authentication delay time calculation unit configured to calculate, for each of the plurality of base stations, an average authentication delay time which is the average value of the elapsed time from a connection request from a communication terminal connected to the base station until a contract for the communication terminal to connect to the base station is concluded; and a contract time calculation unit configured to calculate, for each of the plurality of base stations, a value obtained by subtracting the average authentication delay time from the estimated usage time as the contract time.
3. The communication system according to claim 1 or 2, characterized in that the selection unit is configured to select the second base station based on the contract time of each base station 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 valid period of the contract for a first communication terminal to connect to a base station, based on the wireless communication quality observed by the communication terminal at the time when any of the communication terminals connect to a base station and at the time when the communication terminal switches its connection destination, and the rate of change of wireless communication quality observed by the first communication terminal connected to the first base station; a selection unit configured to select a second base station to switch to from a set of base stations to which the first communication terminal can connect, before the first communication terminal switches its connection destination; and a notification unit configured to notify the first communication terminal 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 contract 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 contract time has elapsed, wherein the contract time of said base station to which the connection will be switched is calculated based on the received power observed by either communication terminal at the time when either communication terminal connects to said base station to which the connection will be switched and at the time when either communication terminal switches the connection destination.
7. A program characterized in that it causes a communication terminal to execute a connection request procedure to receive the base station to which the connection will be switched and the contract time of said base station before switching the connection destination base station, and a switching control procedure to switch the connection destination base station after the contract time has elapsed since the connection destination was switched to said base station, wherein the contract time of said base station to which the connection will be switched is calculated based on the received power observed by either communication terminal at the time when either communication terminal connects to said base station to which the connection will be switched and at the time when either communication terminal switches the connection destination.
8. A contract time management method characterized in that, when a communication terminal switches to a base station it is connected to, a computer performs a procedure to calculate the contract time for each base station such that the overlap period of contract time recorded in the blockchain network for the two base stations before and after the switch is shortened.