Methods, architectures, apparatuses and systems directed to transaction management in blockchain-enabled wireless systems

Abstract

The invention provides programs, methods, architectures, devices, systems, apparatuses, and computer program products for transaction management in blockchain-enabled wireless systems. One of these methods includes obtaining data from one or more sources and one or more parameters from at least one of those sources; generating a transaction for the data based at least in part on the one or more parameters; determining a node of a distributed ledger based at least in part on the one or more parameters; and sending the transaction to the node of the distributed ledger.

Description

Prior Technology

[0001] This application relates to wired and / or wireless communications, including procedures, for example, related to transaction management in a blockchain-enabled wireless system. Simple Explanation of the Diagram

[0002] A more detailed understanding can be obtained from the following embodiments by way of examples combined with the accompanying drawings. Similar to the embodiments, there are examples of such diagrams. Thus, the drawings and embodiments are not considered as limitations, and other equally valid examples are feasible and possible. Furthermore, similar element symbols ("ref.") in the figures indicate similar elements, and wherein: [Figure 1A] is a system diagram illustrating the example communication system; [Figure 1B] is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used in the communication system shown in Figure 1A; [Figure 1C] is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used in the communication system illustrated in Figure 1A; [Figure 1D] illustrates a system diagram of further instances RAN and CN that can be used within the communication system shown in Figure 1A; [Figure 2] illustrates the workflow of an example blockchain system; [Figure 3] A timeline of instances related to processing new transactions at a blockchain node; [Figure 4] is a block diagram illustrating a communication system configured as a 5G system (5GS); [Figure 5] illustrates the various procedures in 5GS; [Figure 6] illustrates an example policy control reference architecture for non-dialogue management-related policy controls; [Figure 7] illustrates an example policy control reference architecture for dialogue management-related policy controls; [Figure 8] illustrates the instance data storage architecture; [Figure 9] illustrates the example network analysis architecture; [Figure 10] illustrates an example of a non-roaming 5G location service architecture; [Figure 11] illustrates an example of the use case of vehicle-to-everything (V2X) connectivity; [Figure 12] illustrates the use cases of smart manufacturing and logistics; [Figure 13] illustrates the integrated blockchain and wireless system architecture; [Figure 14] illustrates an example functional architecture for blockchain transaction management; [Figure 15] illustrates an example functional architecture for blockchain transaction management; [Figure 16] illustrates an example program for constructing trades controlled by a trade manager; [Figure 17] illustrates an example program for constructing trades controlled by a trade manager; [Figure 18] illustrates an example program for constructing trades controlled by a trade manager; [Figure 19] illustrates an example program for constructing transactions controlled by a trading client; [Figure 20] illustrates an example program for constructing transactions controlled by a trading client; [Figure 21] illustrates an example program for blockchain construction aided by a transaction manager; [Figure 22] illustrates an example program for constructing transactions controlled by a transaction manager for multiple blockchains; [Figure 23] illustrates an example of transaction construction across multiple blockchains; [Figure 24] illustrates an example program for querying existing transactions from one or more specified blockchains; [Figure 25] illustrates the procedure for subscribing to events on the blockchain network; [Figure 26] illustrates an analytics-based access control procedure for blockchain networks; [Figure 27] Illustrate Instance 5GS Architecture Extension A with Blockchain Application Enablement; [Figure 28] Illustrate an instance of the 5GS architecture extension B with blockchain application enabled; [Figure 29] illustrates an example program for constructing trades controlled by a trade manager; [Figure 30] illustrates an example program for transaction construction coordinated by the transaction manager; [Figure 31] illustrates an example program used for constructing coordinated transactions; [Figure 32] illustrates the transaction construction triggered by the WTRU instance; [Figure 33] illustrates the transaction construction triggered by the WTRU instance; [Figure 34] illustrates the transaction construction triggered by the WTRU instance; [Figure 35] illustrates the transaction construction triggered by the instance WTRU; and [Figure 36] illustrates the transaction construction triggered by instance WTRU. Implementation

[0003] Cross-referencing of related applications

[0004] This application claims priority to U.S. Provisional Patent Application No. 63 / 045,835, filed June 30, 2020, which is incorporated herein by reference.

[0005] In the following embodiments, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without using some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may replace or be combined with embodiments and other example practices described, disclosed, or otherwise expressly, implicitly, and / or inherently provided herein (collectively, the “provided”). While various embodiments in which devices, systems, apparatuses, etc., and / or any elements thereof perform operation, procedures, algorithms, functions, etc., and / or any part thereof are described and / or claimed herein, it should be understood that any embodiments described and / or claimed herein assume that any device, system, apparatus, etc., and / or any element thereof is configured to perform any operation, procedure, algorithm, function, etc., and / or any part thereof. [Example Communication System]

[0006] The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. Wired networks are well-known. Figures 1A through 1D provide an overview of various types of wireless devices and infrastructures, in which various network elements can utilize, perform, configure, and / or adapt and / or configure for use with the methods, apparatus, and systems provided herein.

[0007] Figure 1A is a diagram of one or more example communication systems 100 that may be implemented according to the disclosed embodiments. The example communication system 100 is provided for illustrative purposes only and is not intended to limit the disclosed embodiments. The communication system 100 may be a multi-access system that provides content (such as voice, data, video, signaling, broadcasting, etc.) to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail (ZT) unique-word (UW) discrete Fourier transform (DFT) extended OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), and similar methods.

[0008] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU 102a, 102b, 102c, 102d (any of which may be referred to as a "station" and / or "STA") may be configured to transmit and / or receive wireless signals and may include (or be) user equipment (UE), mobile radio, fixed or mobile subscriber unit, subscription-based unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, laptop, personal computer, wireless sensor, hotspot or Mi-Fi device, Internet of Things (IoT) device, watch or other wearable, head-mounted display (HMD), vehicle, drone, medical device and application (e.g., remote surgery), industrial device and application (e.g., robot and / or other wireless device operating in the context of industrial and / or automated processing chains), consumer electronics device, device operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d may be referred to as WTRUs interchangeably.

[0009] The communication system 100 may also include base stations 114a and / or 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d, for example, to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or Network 112. For example, base stations 114a and 114b may be any of a base transceiver station (BTS), Node-B (NB), eNode-B (eNB), Home Node-B (HNB), Home eNode-B (HeNB), gNode-B (gNB), NR Node-B (NR NB), station controller, access point (AP), wireless router, and the like. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0010] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a specific geographic area that may be relatively fixed or changeable over time. The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology, and multiple transceivers may be used for each sector of the cell or any sector. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0011] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via an air interface 116. This air interface can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).

[0012] More specifically, as mentioned above, communication system 100 may be a multi-access system and may employ one or more access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and similar schemes. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 may implement radio technologies, such as using wideband CDMA (WCDMA) to establish Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA) on air interfaces 115 / 116 / 117. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0013] In one embodiment, base stations 114a and WTRUs 102a, 102b, 102c may implement radio technologies, such as Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro), to establish Evolved UMTS Terrestrial Radio Access (E-UTRA) on the air interface 116.

[0014] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

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

[0016] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions to / from various types of base stations (e.g., eNBs and gNBs).

[0017] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity, Wi-Fi), IEEE 802.16 (i.e., Global Interoperability Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Evolution Enhanced Data Rate (EDGE), GSM EDGE (GERAN), and the like.

[0018] Base station 114b in Figure 1A can be a wireless router, home node B, home eNode-B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as business premises, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one embodiment, base station 114b and WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of the following: small cell, picocell, or femtocell. As shown in FIG1A, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0019] RAN 104 / 113 can communicate with CN 106 / 115 and can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data can have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 / 115 can provide call control, billing services, location-based services, prepaid telephone, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113 (which may utilize NR radio technology), CN 106 / 115 can also communicate with another RAN (not shown) that uses any of the following radio technologies: GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi.

[0020] CN 106 / 115 may also function as a gateway for WTRU 102a, 102b, 102c, and 102d to access PSTN 108, Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 114 or a different RAT.

[0021] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may employ cellular-based radio technology, and with base station 114b, which may employ IEEE 802 radio technology.

[0022] Figure 1B is a system diagram of example WTRU 102. Example WTRU 102 is provided for illustrative purposes only and is not intended to limit the disclosed embodiments. As shown in Figure 1B, WTRU 102 may include, in particular, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138, etc. It will be understood that WTRU 102 may include any combination of the above-described elements while remaining consistent with one embodiment.

[0023] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. Processor 118 may perform signal encoding / decoding, data processing, power control, input / output processing, and / or any other functionality that enables WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1B depicts processor 118 and transceiver 120 as separate components, it will be understood that processor 118 and transceiver 120 may be integrated together, for example, in an electronic package or on a chip.

[0024] Transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, for example, transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In one embodiment, transmit / receive element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0025] Additionally, although the transmit / receive element 122 is depicted as a single element in FIG. 1B, the WTRU 102 may include any number of transmit / receive elements 122. For example, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals through the air interface 116.

[0026] Transceiver 120 can be configured to modulate signals to be transmitted via transmit / receive element 122 and demodulate signals received via transmit / receive element 122. As mentioned above, WTRU 102 may have multi-mode capability. Therefore, for example, transceiver 120 may include multiple transceivers for enabling WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

[0027] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from them. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 can access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. Non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, processor 118 may access information from memory not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in that memory.

[0028] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

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

[0030] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (e.g., for photographs or videos), universal serial bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency modulated (FM) radio units, digital music players, media players, video game console modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, and the like. Peripheral device 138 may include one or more sensors, such as gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

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

[0032] Figure 1C is a system diagram of RAN 104 and CN 106 according to another embodiment. As mentioned above, RAN 104 can use E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0033] RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with one embodiment. Each of eNode-Bs 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, eNode-B 160a, for example, may use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0034] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), and the like. As shown in Figure 1C, the eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0035] The core network 106 shown in Figure 1C may include a mobility management gateway (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway 166. Although each of the above elements is depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0036] The MME 162 can connect to each of the eNode-B 160a, 160b, and 160c in RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can be responsible for authenticating users of WTRU 102a, 102b, 102c, and similar devices, bearer activation / deactivation, and selecting specific service gateways during the initial attachment of WTRU 102a, 102b, 102c, and similar devices. The MME 162 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0037] The SGW 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can also perform other functions, such as anchoring the user plane during inter-eNode-B handover, triggering calls and / or mobile terminals when DL data is available to WTRUs 102a, 102b, and 102c, managing and storing background information for WTRUs 102a, 102b, and 102c, and similar functions.

[0038] SGW 164 can also be connected to PDN gateway 166, which can provide access to packet switching networks (such as Internet 110) to WTRU 102a, 102b, 102c to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0039] CN 106 can facilitate communication with other networks. For example, CN 106 can provide access to circuit-switched networks (such as PSTN 108) to WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN 106 may include an IP gateway (e.g., an IP multimedia subsystem (IMS) server) or be able to communicate with such IP gateway, which acts as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide access to other networks 112 to WTRUs 102a, 102b, and 102c, which may include other wired or wireless networks owned and / or operated by other service providers.

[0040] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, it is envisioned that in some representative embodiments, this terminal may be used with a communication network (e.g., temporarily or permanently) with a wired communication interface.

[0041] In a representative embodiment, other network 112 may be a WLAN.

[0042] In Basic Service Set (BSS) mode, a WLAN may have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. APs may have access or interfaces to a Distribution System (DS) or another type of wired / wireless network that loads and / or loads traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for STAs can reach and be delivered to those STAs via the AP. Traffic originating from STAs and destined for destinations outside the BSS can be sent to the AP for delivery to individual destinations. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer traffic. Peer traffic can be sent between a source STA and a destination STA (e.g., directly between them) using a direct link setup (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0043] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish connections with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs including the AP (e.g., each STA) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA can go offline. A STA (e.g., only one station) can transmit at any given time within a given BSS.

[0044] High-throughput (HT) STAs can use 40 MHz wide channels for communication, for example, by combining a 20 MHz main channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0045] The Very High Throughput (VHT) STA supports channels of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz width. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels (referred to as an 80+80 configuration). For the 80+80 configuration, after channel encoding, data can be transmitted through a segment parser that can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. Streams can be mapped to two 80 MHz channels, and data can be transmitted via the transport STA. At the receiver receiving the STA, the above operation for the 80+80 configuration can be reversed, and the combined data can be sent to the Medium Access Control (MAC).

[0046] The 1 GHz operating submode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support Meter Type Control / Machine-Type Communications (MTC), such as MTC devices in large coverage areas. MTC devices may have certain capabilities, such as limited capabilities including supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices may include battery packs with a battery pack life exceeding the critical limit (e.g., to maintain a very long battery pack life).

[0047] WLAN systems supporting multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA supporting the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, even if the AP (and other STAs in the BSS) supports 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes, the primary channel can be 1 MHz wide for STAs supporting (e.g., only supporting) the 1 MHz mode (e.g., MTC type devices). Carrier sensing and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. For example, if the main channel is busy, for example because the STA (which only supports 1 MHz operating mode) transmits to the AP, even if most of the frequency band remains idle and available, the entire available frequency band can be considered busy.

[0048] In the United States, the available frequency band (which can be used by 802.11ah) ranges from 902 MHz to 928 MHz. In South Korea, the available frequency band ranges from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band ranges from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz.

[0049] Figure 1D is a system diagram illustrating RAN 113 and CN 115 according to one embodiment. As mentioned above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0050] RAN 113 may include gNBs 180a, 180b, and 180c, although it should be understood that RAN 113 may include any number of gNBs while remaining consistent with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a, for example, may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0051] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable set of parameters. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various lengths or scalable lengths (e.g., containing a varying number of OFDM symbols and / or a continuously varying absolute time length).

[0052] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more gNBs 180a, 180b, and 180c as operational anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can use signals in unlicensed frequency bands to communicate with gNBs 180a, 180b, and 180c. In a non-independent configuration, WTRUs 102a, 102b, and 102c can communicate with / connect to gNBs 180a, 180b, and 180c, while also communicating with / connecting to another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to substantially simultaneously communicate with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-independent configuration, eNode-B 160a, 160b, and 160c can act as mobile anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or throughput for servicing WTRU 102a, 102b, and 102c.

[0053] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Function (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Function (AMF) 182a and 182b, and similar functions. As shown in Figure 1D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

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

[0055] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different packet data unit (PDU) conversations with different requirements), selecting specific SMF 183a and 183b, managing login zones, terminating NAS signaling, mobility management, and similar functions. Network slices can be used by AMF 182a and 182b, for example, to customize CN support for WTRU 102a, 102b, and 102c based on the type of service being used by the WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and / or similar. AMF 162 can provide control plane functions for switching between RAN 113 and other RANs (not shown) that use other radio technologies (such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies (such as Wi-Fi)).

[0056] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b and configure the routes for traffic passing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU conversations, controlling policy enforcement and QoS, providing downlink data notifications, and similar functions. PDU conversation types can be IP-based, non-IP-based, Ethernet-based, and similar.

[0057] UPF 184a and 184b can be connected via an N3 interface to one or more gNBs 180a, 180b, and 180c in RAN 113. This interface can provide access to packet-switched networks (such as Internet 110) to WTRU 102a, 102b, and 102c, for example, to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0058] CN 115 can facilitate communication with other networks. For example, CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 115 may provide WTRU 102a, 102b, 102c with access to other networks 112, such other networks may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU 102a, 102b, 102c may be connected to the local area data network (DN) 185a, 185b via the N3 interface to UPF 184a, 184b and the N6 interface between UPF 184a, 184b and DN 185a, 185b.

[0059] Based on the corresponding descriptions in Figures 1A to 1D, one or more or all of the functions described herein related to any of the following can be performed by one or more emulation elements / devices (not shown): WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other element(s) / device(s) described herein. An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

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

[0061] One or more emulation devices can perform one or more (including all) functions while not being implemented / deployed as a wired and / or wireless communication network. For example, emulation devices can be used in test scenarios in test laboratories and / or non-deployed (e.g., test) wired and / or wireless communication networks to perform tests on one or more components. One or more emulation devices can be test instruments. Wireless communication via direct RF coupling and / or through an RF circuit system (e.g., which may include one or more antennas) can be used by the emulation device to transmit and / or receive data. [introduce] [Blockchain Technology]

[0062] Blockchain technology utilizes and builds upon various existing technologies, such as cryptography, hashing, Merkle trees, decentralized ledgers, peer-to-peer (P2P) networks, and consensus protocols. Blockchain innovatively combines these existing technologies to create systems that offer advanced features such as decentralization, immutability, transparency, and security.

[0063] A blockchain system is a system that utilizes blockchain technology. Applications supported by a blockchain system are called blockchain applications. A blockchain system is supported by one or more basic blockchain networks. Each blockchain network may include a plurality of (e.g., many) participating blockchain nodes (BCNs). Each BCN can host one or more decentralized blockchains (in the form of a decentralized ledger), broadcast blocks using a P2P network, and execute consensus protocols with other BCNs in the blockchain network to achieve decentralized trust and data consistency without relying on a centralized party.

[0064] Blockchain transactions can be any digital representation of real-world transactions, digital records of physical assets, digital records of physical events, digital records of any actions in an information system, digital payments, and any digital smart contracts. A block groups multiple blockchain transactions together. A blockchain is a data structure of blocks with an increasing number of linked blocks.

[0065] For the sake of simplicity, the term "blockchain technology" is used in this document. It should be understood that this term also refers to the broader concept of decentralized ledger technology. Thus, various embodiments can be applied to any specific blockchain technology and / or decentralized ledger technology.

[0066] Figure 2 illustrates an example workflow of a blockchain system. The workflow may include initiating a transaction (1), broadcasting and verifying the transaction (2), creating a new block (3), verifying the new block based on the consensus protocol (4), and updating the blockchain (5). • Initiating a Transaction: Each participating user can independently generate a new transaction. Each user can have a user identifier and / or an account identifier. The user identifier and / or account identifier can be a hash of the user's public key ("user's public key"). Each new transaction is signed using the user's private key. After a new transaction is generated, the user can send it to the blockchain network. • Broadcasting and Transaction Verification: New transactions can be received by some BCNs. Transaction may include the user's public key. The BCN can verify its integrity using the user's public key, and after verification, if the new transaction is valid, it can be relayed and / or broadcast within the blockchain network. Ultimately, all blockchain nodes receive and own a copy of any newly generated and valid transactions. • Creating a new block: Some BCNs (called mining nodes) begin grouping many newly generated and pending transactions together to produce a new block. The new block may include a block header and a block body. The block header may include the hash of the current block, the hash of previously confirmed blocks, and the hash of all included transactions (e.g., a Merkle tree). Depending on the consensus protocol used, the block header may include other and / or additional information. The block body may include the contents of all included transactions. Each mining node can independently attempt to build a new block. • Verify new blocks based on consensus protocols. In the task of creating a new block, mining nodes can independently attempt to build it. They can all run the same consensus protocol (e.g., Proof-of-Work in the Bitcoin system) and agree on who (i.e., the winner) is allowed to insert the block into the existing blockchain. The winner of the consensus protocol can send its newly generated block to the blockchain network. This new block can be broadcast; allowing all mining nodes to receive and / or verify it. • Update the blockchain. Once a newly generated block is verified, it can be successfully appended to the existing blockchain because it includes a hash of the previous blockchain.

[0067] Figure 3 illustrates an instance timeline related to processing new transactions within the BCN. The timeline shows the transaction and block states during the periods between the various stages of processing a new transaction. These periods may include transaction construction time, transaction waiting time, and transaction confirmation time (or blockchain confirmation time).

[0068] Transaction construction time can refer to the period between the time the request to construct a new transaction is received and the time the new transaction is constructed. During the transaction construction time, the transaction status can be "not constructed".

[0069] Transaction wait time refers to the period between the time it takes to construct a new transaction and the time it takes to include the new transaction in a new block. The duration of transaction wait time can depend on the basic P2P network and consensus mechanism. During the transaction wait time, both the transaction state and the block state can be "pending".

[0070] Transaction confirmation time (or blockchain confirmation time) indicates the period between the time a new transaction is included in a new block and the time the new block is confirmed. The duration of transaction confirmation time (or blockchain confirmation time) can depend on the underlying P2P network and consensus mechanism. During transaction confirmation time (or blockchain confirmation time), the transaction status can be "included," and the block status can be "pending." After block confirmation, its status can be "confirmed."

[0071] The speed of a transaction can be assessed as the sum of the transaction waiting time and the transaction confirmation time.

[0072] Figure 4 is a block diagram illustrating a communication system 100 (Figure 1) configured as (e.g., as defined by 3GPP) a 5G system (5GS). The communication system 100 may include RAN 113 and CN 115. One design principle of the 5GS architecture is service-centric or service-based.

[0073] CN 115 may include various network functions. These network functions may work together to provide and / or provide services to RAN 113, WTRU 102, and / or application server / service providers. Network functions may include network repository function (NRF), access and mobility management function (AMF), conversation management function (SMF), authentication server function (AUSF), policy control function (PCF), user plane function (UPF), network exposure function (NEF), unified data management (UDM), unified data repository (UDDR), unstructured data storage function (UDSF), network data analytics function (NWDAF), and network slice selection function (NSSF).

[0074] A network function can access another network function. Network functions can access and / or interact with each other in either request / response or subscription / notification modes. A network function can be NRF logged in. NRF logging in makes the network function discoverable by other network functions.

[0075] The AMF manages access to or mobility of the WTRU 102 in the communication system 100. The SMF is responsible for establishing a dialogue between the WTRU 102 and CN 115. The AUSF is responsible for authenticating users (e.g., WTRUs). The PCF constructs and / or provides one or more policy rules for and / or other control plane network functions and the WTRU 102. The PCF assigns identifiers to the constructed policy rules, and other control plane network functions and the WTRU 102 can use these identifiers to reference (e.g., look up or otherwise obtain) the corresponding policy rules.

[0076] UPF can be used for user plane functions. UPF can monitor, manage, control, and redirect user plane traffic flows, such as between WTRU and application servers. NEF can expose control plane functions to entities outside the 5GS and / or not in the same trusted domain (e.g., network applications).

[0077] The CN can provide data storage and analysis services through functions such as UDM, UDR, UDSF, and any of NWDAF. The communication system can support network slicing. Network slicing can be facilitated by NSSF.

[0078] While network functions can be defined as separate logical entities, some or all of them can be combined. One or more network functions may be associated with specific procedures or operations and / or uses. For example, AMF, AUSF, and SMF may relate to WTRU mobility. One or more instances of network functions can be instantiated. NRF can maintain information about each network function instance. Although displayed within a single cloud, one or more network functions can be deployed in edge networks, such as edge computing support and / or edge networks located near and / or co-located with RAN 113. Deploying UPF and / or NEF in edge computing support edge networks can be advantageous because policy controls can be applied directly to events / data at the edge (i.e., where data / events are generated), which can save on certain communication costs.

[0079] Figure 5 illustrates the various programs in the 5GS. For convenience, the various programs are described with reference to the communication system 100 in Figure 4. The various programs can also be implemented using other architectures. For ease of explanation and simplicity, the component symbols accompanying Figure 5 are prefixed with "5:" in this disclosure.

[0080] As indicated in (5:1), the WTRU can discover and / or select networks (e.g., PLMN, RAN, cells, etc.) based on received system information blocks (SIBs) broadcast by one or more RAN nodes. As indicated in (5:2), the WTRU can establish a radio resource control (RRC) connection with the selected RAN (e.g., RAN1). The WTRU can communicate with the 5GS CN via the selected RAN. As indicated in (5:3), the WTRU can initiate a login to an AMF. The selected RAN can determine / select the serving AMF for the WTRU from one or more AMFs. As indicated in (5:3), the serving AMF can use the ASF to check primary access authentication and authorization, request subscription data from the UDM, use the PCF to check access and mobility policies, and / or contact the SMF to initiate any existing PDU conversation (e.g., if instructed by the WTRU).

[0081] A login area (RA) can be defined within 5GS. An RA can be formed from one or more tracking areas (TAs); each of these can cover one or more cells. One advantage of an RA is that, when within an RA, signaling overhead is reduced by not needing to update the login in the serving AMF unless a periodic login timer expires. If a WTRU moves from one RA (e.g., RA1) to another RA (e.g., RA2), the WTRU can perform a new login, such as, for example, using a login type configured for mobility login updates (as described herein and indicated in (5:7)). Larger RAs can reduce login overhead, but may increase call signaling overhead because the serving AMF must call the WTRU from a larger number of TAs (or cells).

[0082] Upon successful login, the WTRU can enter the RM-REGISTERED state and / or access and / or interact with other control planes (NFs) via the Serving AMF. In various embodiments, the Serving AMF may be the sole entry point for the WTRU to access and interact with the CN control plane. The procedures indicated in (5:3), (5:5), and (5:7) may, for example, be related to connection management.

[0083] As indicated in (5:4), the WTRU can use the SMF to establish a PDU session for the DN. The serving AMF can determine / select the serving SMF for the PDU session. As indicated in (5:4), the SMF can use the PCF to check the PDU session policy and / or select the UPF as the anchor for the PDU session ("PDU session anchor"). The WTRU can access the DN and / or exchange packets with the DN via the PDU session anchor (PSA). The PCF can retrieve the WTRU's subscription information from the UDR and can provide it to the SMF, which relates to the SMF's use of the PCF to check the session policy. The SMF can perform primary session authentication using the WTRU's subscription information, such as that retrieved from the UDM, and can perform secondary authentication between the WTRU and the DN-AAA server, for example, using an extensible authentication protocol (EAP) as defined in RFC3748 and RFC5247. The program represented in (5:4) and the program represented in (5:5) can be executed together.

[0084] As indicated in (5:5), the WTRU can be in the CM-IDLE state (e.g., after the connection with the serving AMF has been released) and can initiate a service request procedure to re-establish the connection with the serving AMF and enter the CM-CONNECTED state. When the WTRU initiates the service request procedure to re-establish the connection with the serving AMF, it can be in mobile initiated connections only (MICO) mode. If the WTRU is not in MICO mode, the serving AMF can call and / or trigger the WTRU to initiate the service request procedure, for example, to receive any downlink packets. A non-access-stratum (NAS) connection can be established between the WTRU and the serving AMF associated with the service request.

[0085] Service requests can be made concurrently with WTRU login, in which case the WTRU can enter the CM-CONNECTED state. While in the CM-CONNECTED state, the WTRU can move within the RA without notifying the serving AMF. If the WTRU remains within the RA but moves out of the RAN notification area (RNA), the WTRU can perform a RAN update to trigger an RAN update of the WTRU background maintained by that RAN and the corresponding RRC connection. The RNA can be smaller than the RA. For example, the RNA can include a subset of the TAs forming the RA (e.g., TA1, TA2, and TA3, as shown in the figure).

[0086] As shown in (5:6), the WTRU can perform data transmission (data plane) via RAN 113 and the UPF as a PSA using a DN. The DN may have a data network name (DNN). Although not illustrated, the 5GS may include and / or communicatively couple more than one DN, and each DN may have a separate DNN.

[0087] As indicated in (5:7), the WTRU can detect when it moves from RA1 to RA2. For example, the WTRU can detect such events by checking the list of TAs used by each RA configured by the serving AMF. As indicated in (5:7), the WTRU can perform an action logon update using the new serving AMF. As indicated in (5:7), RAN handover (e.g., Xn-based or N2-based) from the current RAN to a new RAN can be performed as the serving AMF changes. The new serving AMF can access the old serving AMF to transfer the WTRU's background information. As indicated in (5:7), the SMF can access the PCF and / or UPF to update existing PDU conversations using the WTRU.

[0088] As shown in Figure 5, multiple TAs can be grouped together as a local area data network (LADN) service area to support LADN services. As an example, TA4, TA5, and TA6 can form an LADN service area. If (for example, if and only if) the WTRU remains within TA4, TA5, or TA6, that WTRU is allowed to access LADN1.

[0089] A group of TAs can be grouped into a service area. 5GS can specify and / or enforce service area restrictions on WTRUs. For example, 5GS can configure WTRUs for service area restrictions used to form service areas from TA7, TA8, and TA9, wherein WTRUs are allowed to access 5GS if (e.g., if and only if) a WTRU remains within TA7, TA8, or TA9.

[0090] The various procedures shown and illustrated in Figure 5 do not need to be executed in the order shown or described, and not all procedures need to be executed. For example, the procedure shown in (5:7) may be executed before the procedure shown in (5:6), and the procedure shown in (5:5) does not need to be executed. [Representative Policy Control Function] [(Policy Control Function, PCF)]

[0091] Policy controls in 5GS can include non-dialogue management-related policy controls and dialogue management-related policy controls. Figure 6 illustrates a reference architecture for example policy controls used for non-dialogue management-related policy controls. Figure 7 illustrates a reference architecture for example policy controls used for dialogue management-related policy controls. The Charging Function (CHF) is described in Figure 7.

[0092] Examples of non-dialogue management-related policy controls include access and mobility-related policy controls, WTRU access selection and PDU dialogue selection-related policy controls (WTRU policy), Packet Flow Description (PFD) management, and network state analysis information requirements. Examples of dialogue management-related policy controls include QoS control for PDU dialogues and Service Data Flow (SDF), charge control for PDU dialogues and SDF, reporting PDU dialogue events to the AF, usage monitoring control, application detection policy controls, service capability disclosure policy controls, and traffic redirection policy controls.

[0093] PCF provides various functionalities for both non-dialogue management-related policy control and dialogue management policy control. PCF can provide different policies to control plane functions (e.g., AMF, SMF, NEF), WTRU, and AF) that execute the provided policies. PCF can retrieve subscription data from UDR to construct new policies. Operators can configure policies in PCF. Policies can be stored in UDR. Policies can be configured dynamically, semi-statically, and / or statically on various entities, devices, etc., such as AMF, SMF, and WTRU.

[0094] For example, access and mobility-related policy controls can include management of service area restrictions, management of RAT / frequency selection priority (RFSP) functionality, and management of SMF selection. The service AMF and PCF can perform an "AM Policy Association Establishment" for the WTRU (e.g., when the WTRU performs an initial login and selects (e.g., selects only the service AMF). The service AMF and PCF can exchange access and mobility-related policies, for example, after the AM Policy Association Establishment.

[0095] Based on operator-defined policies, the PCF can modify the service area restrictions used for the WTRU as part of its subscription data. The operator-defined policy in the PCF may depend on input data such as the WTRU's location, time of day, and information provided by other NFs. When the WTRU logs in as a service AMF, the service AMF can retrieve its service area restrictions from the UDM as part of its subscription data. The service AMF can report the service area restrictions to the PCF. The PCF can modify the service area restrictions and / or can send the modified service area restrictions to the service AMF. The AMF can store the modified service area restrictions and / or can execute the modified service area restrictions to determine the portability restrictions used for the WTRU.

[0096] The RFSP index can be used by the serving AMF to manage radio resources for the WTRU. The PCF can modify the RFSP index, for example, based on operator-defined policies. For example, the operator-defined policies in the PCF may depend on input data such as cumulative usage, load level information per network slice instance, etc. When the WTRU logs in with the serving AMF, the serving AMF can retrieve the RFSP index from the UDM, for example, as part of its subscription data. The serving AMF can report the RFSP index to the PCF. The PCF can modify the RFSP index and / or send it to the serving AMF. The AMF can send the modified RFSP index to the (R)AN node. The RAN node can execute the modified RFSP index.

[0097] The PCF can configure the WTRU with various policies via the serving AMF. These policies may include an access network discovery and selection policy (ANDSP) for non-3GPP access, and a WTRU route selection policy (URSP) related to applications and PDU conversations. The WTRU can use URSP rules to determine whether to use an established PDU conversation for an application and / or trigger the establishment of a new PDU conversation, for example, based on traffic descriptors specified in matching criteria included in (e.g., each) URSP rules. If the WTRU is in CM-IDLE state, the serving AMF can send a call message to the WTRU to trigger the WTRU to execute the WTRU Initiation Service Request procedure, allowing the serving AMF to deliver ANDSP and URSP (received from the PCF) to the WTRU.

[0098] Application detection, as a type of dialogue management-related policy control, can be provided through interactions between the PCF, SMF, and UPF. The PCF can install (or initiate) one or more policy and charging control (PCC) rules that include actions to be taken against the SMF. The SMF can instruct the UPF to detect events on specific application traffic. The UPF can impose configured enforcement actions on specific application traffic, such as gate control (e.g., blocking application traffic), QoS control (e.g., bandwidth limiting), and traffic redirection.

[0099] UPF can detect events and report detected events to PCF via SMF. PCF can modify PCC rules and / or install modified PCC rules to SMF based on one or more reported events. [Representative Data Storage Architecture]

[0100] Figure 8 illustrates an example instance data storage architecture for 5GS. Data storage may include UDM, UDR, and UDSF. UDR may be implemented within a UDM, PCF, or NEF (e.g., as part of it). A UDR may function as multiple UDMs, PCFs, and NEFs. UDSF may be implemented within an NF (e.g., as part of it). A UDSF may function as multiple NFs. UDR and UDSF may be co-located.

[0101] Data in a communication system can be categorized into unstructured data and structured data. Unstructured data can be any type of data. Structured data may include subscription data, policy data, structured data for disclosure, and application data (such as packet flow descriptions (PFDs) for application detection and AF request information for multiple WTRUs).

[0102] Examples of available data storage capabilities may include: (i) a UDM that can store subscription data to and / or retrieve subscription data from the UDR; (ii) a PCF that can store policy data to and / or retrieve policy data from the UDR; (iii) a NEF that can store structured data and / or application data for disclosure to and / or retrieve such data from the UDR; (iv) an NF that can store unstructured data to and / or retrieve unstructured data from the UDSF; (v) a UDR that allows NF consumers to retrieve, build, update, subscribe to, unsubscribe from, and / or delete data stored in the UDR, for example, based on a dataset applicable to NF consumers; and (vi) a UDSF that allows NF consumers to retrieve, build, update, and delete data stored in the UDSF.

[0103] The UDM can provide any of the following functionalities: (i) generating (e.g., 3GPP) authentication and key agreement (AKA) credentials and / or sending such AKA credentials to the serving AMF (e.g., when the WTRU logs in with the serving AMF); (ii) handling user identification (e.g., storage and / or management of each user's subscription permanent identifier (SUPI) in the 5GS); (iii) supporting the de-concealment of its privacy-protected user concealed identifier (SUCI) based on a privacy-protected SUPI; (iv) authorizing the WTRU to access the 5GS based on its subscription information (such as roaming restrictions); (v) managing the WTRU's service NF (e.g., storing the serving AMF for the WTRU, storing the serving SMF for the WTRU's PDU conversations); (vi) supporting service and conversation continuity (e.g., storing the SMF / DNN assignment for ongoing conversations); and (vii) handling 5G LAN group management. [Representative Network Analysis Architecture]

[0104] 5GS can provide network analytics via Network Data Analysis Function (NWDAF). Figure 9 illustrates an example network analytics architecture. NWDAF can perform a set of analyses (e.g., statistical information related to past events and / or predictive information). This set of analyses can be represented as a list of analysis IDs. NWDAF can be deployed to serve certain areas (i.e., a list of tracking area identities (TAIs)). Multiple NWDAF instances can be deployed within 5GC and / or each NWDAF instance can provide different analysis IDs.

[0105] An NWDAF can register its capabilities (i.e., a list of analysis IDs) with an NRF for discovery by any other NF / AF. Before calculating analysis results, an NWDAF may need to collect data from other NF / AFs that are data sources. An NWDAF can execute corresponding algorithms on each analyzer to obtain analysis results. NF / AFs can discover the NWDAF's analysis IDs from the NRF or directly from the NWDAF. An NF / AF can retrieve specific analysis results from an NWDAF and / or subscribe to specific analyses from an NWDAF. Providing network analysis may require the following stages. • Analytics Login: When logging into the NRF, the NWDAF can send a list of its analytics IDs (e.g., as part of its NWDAF profile) for storage in the NRF. The list of analytics IDs can be discovered by other NF / AFs. NF / AFs can discover NWDAFs from the NRF and can directly discover their analytics IDs from the NWDAFs. • Data Collection: The NWDAF may need to retrieve and collect data from various NF / AF entities that serve as data sources (such as AMF, SMF, UDM, PCF, NRF, NEF, and any AF (possibly via NEF)). When configured by a PLMN operator, the NWDAF may collect relevant management data from services within the OAM (e.g., NG RAN or 5GC performance measurements, any 5G end-to-end KPIs). If the required data for a specific analysis request is available in the NWDAF, the NWDAF may skip data collection. ○ NWDAF may collect behavioral data (e.g., WTRU reachability) and / or overall WTRU information (e.g., the number of WTRUs in a geographic area) from UDM, AMF, SMF, Link Support Function, and NEF. NWDAF can determine UDM, Link Support Function, and NEF from NRF, can determine AMF and SMF from UDM, and / or can determine PCF from Link Support Function. • Calculation of Analysis Results: After collecting the necessary (e.g., required) data for the analysis ID, NWDAF can execute the corresponding analysis algorithm on the collected data to obtain the analysis results for the analysis ID. If NF / AF has subscribed to the analysis ID, NWDAF can send the newly calculated analysis results to NF / AF whenever the analysis results are updated. • Retrieving Analysis Results: NF / AF can send a request for an analysis ID to NWDAF. NWDAF can then send the results of the requested analysis to NF / AF. If the results are unavailable, NWDAF can collect relevant data and calculate the analysis results.

[0106] 3GPP TS 23.288 V16.3.0 (2020-03); Architecture enhancements for 5G systems (5GS) to support network data analysis services; (Release 16) defines procedures to support the following network analyses: (i) slice load level related network data analysis; (ii) observed service experience related network data analysis; (iii) NF load analysis; (iv) network performance analysis; and (v) UE related analysis (e.g., UE mobility analysis, UE communication analysis, expected UE behavior parameter related network data analysis, and abnormal behavior related network data analysis).

[0107] Figure 10 illustrates an example of a non-roaming 5G location service architecture.

[0108] [surface] [1.] [Reference points supporting location services] [Reference Point] [Entities Involved] [Function Description] Le GMLC (or LRF) ↔ LCS Customer LCS customers can send location requests to GMLC (or LRF) via Le. N1 UE ↔ AMF The target UE can send location event reports or location protocol messages to the LMF via the serving AMF. Privacy notifications and verifications related to location services and changes in UE privacy preferences for AMF and target UE transfer. All messages used for location services via N1 will be included in the NAS signaling message. N2 (R)AN ↔ AMF LMF and RAN nodes transfer location information via N2 through AMF. LMF can send certain assistance information to be broadcast by the RAN node to that RAN node. N51 AMF ↔ NEF / NF The NEF or another NF can send a query for the location of the target UE to the serving AMF. N52 UDM ↔ NEF / NF NEF / NF can send queries for privacy subscription information and route information (i.e., service AMF) for a target UE to UDM. NL1 AMF ↔ LMF The serving AMF can send a location request for the target UE to the LMF. The location request can be for the target UE's immediate location or a delayed location, either periodically or after a location event is triggered. NL2 AMF ↔ GMLC GMLC can send a location request for the target UE to the serving AMF. NL5 GMLC ↔ NEF / NF The NEF or another NF can send a location request to the GMLC. NL6 UDM ↔ HGMLC HGMLC can send queries for privacy subscription information and route information (i.e., service AMF) for a target UE to UDM.

[0109] A target WTRU may have one or more privacy requirements regarding sharing and / or disclosing its location to other entities. WTRU LCS privacy allows the WTRU and / or AF to control the features that allow or disallow location requests from its LCS customers or AFs. For example, WTRU LCS privacy information may be provided and / or maintained by: • Via subscription data: The privacy preferences of the target WTRU can be included in the WTRU LCS privacy profile as part of the WTRU subscription data to be stored in the UDM (or UDR). Other entities (such as GMLC and / or NEF) can query the target WTRU's LCS privacy profile via the UDM. • Via dynamic update: The target WTRU and / or AF can update part of the WTRU privacy profile and / or the update can be stored in the UDR.

[0110] LCS can provide the following methods to protect location privacy. • The target WTRU can send updated privacy requirements to the service AMF (for transfer to UDR via UDM). • The AMF service can receive updated privacy requests from the target WTRU and transfer them to the UDR via the UDM. • The UDR can store the target WTRU's privacy information, and it can be updated via the AMF service through the UDM using new privacy information received from the target WTRU. • The UDM may include the WTRU LCS privacy profile. The UDM may be accessed from the AMF, GMLC, and / or NEF. The UDM may provide the WTRU LCS privacy profile to the GMLC and / or NEF, where authorization from location requests from LCS customers or AFs can be performed. • The GMLC can provide LCS customers with access to the PLMN and / or its access directly or via the NEF to the AF and NF. The GMLC can query route information and / or target WTRU privacy information from the UDM, and based on this information, the GMLC can authorize and / or verify the target WTRU privacy for location requests from external LCS customers and / or AFs. The GMLC can forward location requests to the serving AMF (or, in roaming cases, to another GMLC). The GMLC can store information for external LCS customers who are permitted to request the target WTRU's location information. • The NEF can request privacy information about the target WTRU from the UDM. The NEF can support the provision of WTRU LCS privacy profiles from the AF. For direct NEF queries to the Service AMF that do not involve any GMLC (and / or for NEF queries via the UDM), the NEF can determine whether to authorize the AF to retrieve the WTRU location based on the WTRU LCS privacy profile received by the NEF from the UDM.

[0111] The general procedure for requesting the location of a target WTRU using AF may include any of the following: • AF can send LCS location requests to NEF, which can indicate the need for higher accuracy than cell ID level location accuracy. • NEF can forward location requests to GMLC. • GMLC can access the target WTRU's UDM to obtain the target WTRU's route information (i.e., service AMF) and LCS privacy profile. • GMLC can use a retrieved LCS privacy profile from UDM to authenticate location requests. If location requests are allowed, GMLC can forward the location request to the service AMF to request the current location of the target WTRU. • The AMF service can execute network-triggered service requests to contact the target WTRU, for example, if it is in the CM IDLE state. • The AMF service can use NAS signaling to notify the target WTRU of a location request from the AF, for example, if its privacy profile requires such a notification. • The target WTRU can notify the WTRU user of the location request. After the user grants or retains permission for the location request, the target WTRU can send the notification result to the service AMF. • The AMF can be selected using an NRF query, for example. • The service AMF can send a request to the selected LMF to request the current location of the target WTRU. • The LMF can perform some positioning procedures to calculate the current location of the target WTRU. For example, the LMF can send location-related N1 messages to the target WTRU via the serving AMF, and / or send network positioning messages to the RAN node via the serving AMF. • The LMF can send a location response indicating the current location of the target WTRU to the service AMF. This location response may include a location estimate, its age, and accuracy, and may include information about the positioning method. • The AMF service can forward location responses to the GMLC. • If notification (verification) based on the current location of the target WTRU is required (as specified in the LCS privacy profile), the GMLC may send the notification to the target WTRU via the service AMF and / or may wait for confirmation from the target WTRU and / or the WTRU user. GMLC can forward location responses to NEF. • NEF can forward location responses to AF.

[0112] This document discloses methods, apparatus, systems, etc., for transaction management in a decentralized ledger (e.g., blockchain) enabled wireless system. In various embodiments, methods for transaction management in a decentralized ledger (e.g., blockchain) enabled system and / or for methods related to such transaction management can be implemented in an apparatus (such as a wireless transmit and receive unit (WTRU), a base station, or other network element) comprising a circuit system (including a transmitter, a receiver, and a processor). These methods may include a first method of: obtaining (i) information from one or more sources and (ii) one or more parameters from at least one of the one or more sources; generating a transaction for the information based at least in part on the one or more parameters; determining a node of the decentralized ledger based at least in part on the one or more parameters; and sending the transaction to the node of the decentralized ledger.

[0113] Such methods may include a second method of any of the following: obtaining information and / or one or more parameters from one or more sources; generating a transaction for the information based at least in part on the one or more parameters; determining a node of a distributed ledger based at least in part on the one or more parameters; and sending the transaction to the node of the distributed ledger.

[0114] These methods may include a third method of any of the following: obtaining (i) information from one or more sources and (ii) one or more parameters from at least one of the one or more sources; sending at least a first portion of the information to a data storage; generating a transaction based at least in part on the one or more parameters for at least a second portion of the information and a hash value of the at least a first portion of the information; determining a node of a distributed ledger based at least in part on the one or more parameters; and sending the transaction to the node of the distributed ledger.

[0115] The methods may include a fourth method that includes: obtaining information and / or one or more parameters from one or more sources; sending at least a first portion of the information to a data storage; generating a transaction based at least in part on the one or more parameters for at least a second portion of the information and a hash value of the at least a first portion of the information; determining a node of a distributed ledger based at least in part on the one or more parameters; and sending the transaction to the node of the distributed ledger.

[0116] In various embodiments of at least the third and fourth methods, each of the methods may include receiving second information indicating a storage location of the at least one first portion of the information.

[0117] In various embodiments of at least the third method and the fourth method, each of the methods may include dividing the information into at least a first portion of the information and at least a second portion of the information.

[0118] In various embodiments, the node of the distributed ledger may be a first node of the distributed ledger, and in at least one of the first to fourth methods, the method may include receiving a confirmation that the transaction has been successfully inserted into the distributed ledger, wherein the confirmation is received from any one of the first node of the distributed ledger, a second node of the distributed ledger, and a second device associated with at least one of the first node and the second node.

[0119] In various embodiments, the apparatus may include at least one service-based function, wherein the at least one service-based function may perform the generation of a transaction and the determination of a node in a distributed ledger.

[0120] In various embodiments, the method may include notifying one or more recipients of a status of the transaction. In various embodiments, the recipients may include at least one of a first service-based function of the device, a second service-based function of the device, and a third service-based function of a network. In various embodiments, the first service-based function may be a client of the third service-based function. In various embodiments, the second service-based function may be a client of the third service-based function. In various embodiments, the status may be any of pending, confirmed, and rejected.

[0121] In various embodiments, generating a transaction for the data based at least in part on one or more parameters may include generating the transaction for the data based at least in part on one or more parameters and one or more policy rules.

[0122] In various embodiments, the method may include a transaction that generates a hash value for at least a second portion of the data and the at least a first portion of the data based at least in part on one or more parameters.

[0123] In various embodiments, such policy rules include either a first policy rule regulating whether the data is added to the distributed ledger or a second policy rule regulating how the data is added to the distributed ledger.

[0124] In various embodiments, determining a node of a distributed ledger may include determining the node of the distributed ledger based at least in part on the proximity of the device to the node of the distributed ledger.

[0125] In various embodiments, the method may include parameters that may include a first location associated with the first device and a second location associated with the node of the distributed ledger, and the method further includes determining the proximity of the device to the node of the distributed ledger based at least in part on the first location and the second location.

[0126] In various embodiments, these parameters may include any of the following: (i) a number of transactions to be constructed; (ii) an application category associated with each of the one or more sources; (iii) an identifier associated with each of the one or more sources; (iv) an application name associated with each of the one or more sources; (v) security credential information for each of the one or more sources; (vi) an address of the node of the distributed ledger; (vii) an identifier of the node of the distributed ledger; (viii) a category of transactions to be constructed; (ix) a maximum transaction construction time; (x) a maximum transaction waiting time; (xi) a The transaction establishes a priority order; (xii) a transaction includes a priority order; (xiii) one or more addresses where some or all of the data is stored; (xiv) an address of each of the one or more recipients to be notified of a status of the transaction; (xv) an identifier of each of the one or more recipients to be notified of the status of the transaction; (xvi) a type of the distributed ledger; (xvii) an address of the distributed ledger; (xviii) an identifier of the distributed ledger; (xix) a hash function; (xx) an instruction of at least one of the one or more policy rules; and (xxi) security credential information of the device.

[0127] 1. In various embodiments, the method may include obtaining information, which may include requesting and receiving information from at least one of the sources.

[0128] In various embodiments, the information may include any of the following: (i) third information for submission to the distributed ledger and (ii) fourth information indicating any address and identifier for obtaining fifth information for submission to the distributed ledger.

[0129] In various embodiments, the information may lack one or more of the following: (i) a sixth piece of information for submission to the distributed ledger and (ii) a seventh piece of information indicating any of the bit address and an identifier for obtaining an eighth piece of information for submission to the distributed ledger.

[0130] In various embodiments, the method may include receiving transaction record information.

[0131] In various embodiments, the method may include any of the following: sending at least a portion of the transaction record information and second information indicating the storage location of the at least first portion of the information to the data storage; and receiving from the data storage a ninth message indicating that the at least portion of the transaction record information is stored in association with the at least first portion of the information.

[0132] In various embodiments, the method may include sending at least a portion of the information to a data storage, the at least portion of the information; and receiving tenth information indicating a storage location of the at least portion of the information.

[0133] In various embodiments, the method may include sending at least a portion of the transaction record information and tenth information indicating the storage location of the at least portion of the information to the data storage; and receiving from the data storage eleventh information indicating that the at least portion of the transaction record information is stored in association with the at least portion of the information.

[0134] In various embodiments, the method may include obtaining one or more transaction policy rules from one or more sources including any of a first entity and a second entity.

[0135] In various embodiments, obtaining the one or more transaction policy rules includes any person who requests and / or receives the one or more transaction policy rules from the one or more sources.

[0136] In various embodiments, determining a node of the distributed ledger may include selecting the node based on at least one of the one or more transaction policy rules.

[0137] In various embodiments, the information may include data associated with a blockchain transaction.

[0138] The fifth method of this type implements a blockchain transaction manager (BTM) and may include any of the following: receiving a blockchain transaction initiation (BCTI) request from a first entity; obtaining information associated with the blockchain transaction from one or more sources, including the BCTI request and any of a second entity; generating a blockchain transaction containing at least a portion of the obtained information or a hash, wherein the hash identifies at least a portion of the obtained information and / or an indicator / locator for obtaining a portion of the obtained information; sending the blockchain transaction to a blockchain node (BCN) (e.g., on behalf of the first entity); and receiving a status of the blockchain transaction from the BCN.

[0139] In various embodiments, this status can be any of pending, confirmed, or rejected.

[0140] In various embodiments, obtaining information associated with the blockchain transaction may include requesting and / or receiving information associated with the blockchain transaction.

[0141] In various embodiments, the BCTI may include any of the following: (i) data associated with the blockchain transaction, and (ii) an indicator / locator for obtaining the data associated with the blockchain transaction.

[0142] 5. In various embodiments, the BCTI may lack any of the following: (i) data associated with the blockchain transaction, and (ii) an indicator / locator for obtaining the data associated with the blockchain transaction.

[0143] In various embodiments, the method may include selecting the BCN from a plurality of BCNs. In various embodiments, the method may include selecting the BCN based on the acquired data. In various embodiments, the method may include any of the following: storing at least a portion of the acquired data in a storage library; and storing at least a portion of the acquired data in a storage library.

[0144] In various embodiments, storing at least a portion of the acquired data in a repository may include any of the following: requesting a third entity to store the at least portion of the acquired data to be stored in a repository; and sending the at least portion of the acquired data to be stored in a repository to a third entity.

[0145] In various embodiments, the method may include sending the status of the blockchain transaction to the first entity. In various embodiments, the method may include receiving blockchain transaction record information from the BCN.

[0146] In various embodiments, the method may include any of the following: storing at least a portion of the blockchain transaction record information in a repository; and storing at least a portion of the blockchain transaction record information in a repository.

[0147] In various embodiments, the method may include any of the following: receiving blockchain transaction record information from the BCN; storing at least a portion of the blockchain transaction record information in a repository relating to the at least a portion of the acquired data (e.g., in a record); and storing at least a portion of the blockchain transaction record information in the repository relating to the at least a portion of the acquired data (e.g., in a record).

[0148] 14 In various embodiments, storing at least a portion of the blockchain transaction record information in the repository may include any of the following: requesting a third entity to store the at least portion of the blockchain transaction record information in the repository associated with the at least portion of the acquired data; and sending the at least portion of the blockchain transaction record information to be stored in the repository to a third entity.

[0149] In various embodiments, the method may include configuring the BTM using one or more blockchain transaction policy rules. In various embodiments, configuring the BTM using one or more blockchain transaction policy rules may include any of the following: configuring the one or more blockchain transaction policy rules dynamically and semi-statically.

[0150] In various embodiments, configuring the BTM with one or more blockchain transaction policy rules may include obtaining the one or more blockchain transaction policy rules from one or more sources including any of the second entity and a fourth entity.

[0151] In various embodiments, the method may include obtaining the one or more blockchain transaction policy rules, which may include any of the following: requesting and / or receiving the one or more blockchain transaction policy rules from the one or more sources. In various embodiments, the method may include selecting the BCN based on at least one of the one or more blockchain transaction policy rules.

[0152] In various embodiments, the method may include determining, based on at least one of the one or more blockchain transaction policy rules, whether the data associated with the blockchain transaction was requested and / or received from either the second entity or a fifth entity.

[0153] In various embodiments, the method may include selecting the BCN based on at least one of the one or more blockchain transaction policy rules.

[0154] In various embodiments, the method may include storing at least a portion of the acquired data in a repository based on at least one of the one or more blockchain transaction policy rules; and causing at least a portion of the acquired data to be stored in a repository based on at least one of the one or more blockchain transaction policy rules.

[0155] In various embodiments, storing at least a portion of the acquired data in a repository may include any of the following: requesting a third entity to store the at least portion of the acquired data to be stored in a repository; and sending the at least portion of the acquired data to be stored in a repository to a third entity.

[0156] In various embodiments, the method may include determining, based on at least one of the one or more blockchain transaction policy rules, whether a portion of the data associated with the blockchain transaction is stored in a repository.

[0157] In various embodiments, the method may include determining, based on at least one of the one or more blockchain transaction policy rules, whether at least a portion of the blockchain transaction record information is stored in a repository.

[0158] In various embodiments, the method may include determining, based on at least one of the one or more blockchain transaction policy rules, whether at least a portion of the blockchain transaction record information is stored in a repository connected within the repository associated with the at least a portion of the acquired data (e.g., in a record).

[0159] In various embodiments, the BCTI may include data associated with the blockchain transaction. In various embodiments, the BCTI may include an indicator / locator for obtaining data associated with the blockchain transaction.

[0160] In any of the various embodiments including BTM, the BTM can be deployed in any of a RAN node, a CN node, a server, a gateway, and a WTRU. In any of the various embodiments including BTM, the BTM can be a control plane network function.

[0161] In any of the various embodiments including a first entity, the first entity may be deployed in any of a RAN node, a CN node, a server, a gateway, and a WTRU. In any of the various embodiments including a first entity, the first entity may be any of a blockchain client application (BCA), a blockchain transaction client (BTC), and a blockchain network application (BNA).

[0162] In various embodiments including a Blockchain Application Networking Provider (BNA), the BNA may be implemented as an application function (AF) or in combination with such an application function. In various embodiments including a Blockchain Transaction Management Provider (BTM) and a first entity, the BTM and the first entity are deployed in the same apparatus. In various embodiments, the one or more sources from which data associated with the blockchain transaction is obtained may include any of the following: a data and policy provider (DPP), a Blockchain Application Networking Provider (BNA), an Unstructured Data Storage Function (UDSF), and a Unified Data Repository (UDR). In various embodiments including a second entity, the second entity may be a DPP. In various embodiments including a third entity, the third entity may be an external data storage (EDS). In various embodiments including a fourth entity, the fourth entity may be a policy control function (PCF). In various embodiments including a fifth entity, the fifth entity may be any of a Blockchain Application Networking Provider (BNA), an Unstructured Data Storage Function (UDSF), and a Unified Data Repository (UDR). In various embodiments that include a first entity, the method may include sending the blockchain transaction record information to the first entity.

[0163] The sixth method among these methods can perform a de-icing and may include any of the following: sending a Blockchain Transaction Initiation (BCTI) request to a Blockchain Transaction Manager (BTM); receiving one or more states of the blockchain transaction from the BTM; and receiving blockchain transaction record information from either the BTM or another BTM.

[0164] In various embodiments, one or more states may include any of the following: pending, confirmed, and rejected. In various embodiments, the one or more states may include an indication that the BCTI has been successfully processed.

[0165] In various embodiments, the BCTI may include any of the following: (i) data associated with the blockchain transaction, and (ii) an indicator / locator for obtaining the data associated with the blockchain transaction. In various embodiments, the BCTI may lack any of the following: (i) data associated with the blockchain transaction, and (ii) an indicator / locator for obtaining the data associated with the blockchain transaction.

[0166] In at least various embodiments of the sixth method, the method may include a notification that at least a portion of the acquired data is stored in a repository.

[0167] In at least various embodiments of the sixth method, the method may include configuring the device using one or more blockchain transaction policy rules. In at least various embodiments of the sixth method, configuring the device using one or more blockchain transaction policy rules may include any of the following: configuring the one or more blockchain transaction policy rules dynamically and semi-statically.

[0168] In at least various embodiments of the sixth method, configuring the device with one or more blockchain transaction policy rules may include obtaining the one or more blockchain transaction policy rules from one or more sources including BTM and a second entity.

[0169] In at least various embodiments of the sixth method, obtaining the one or more blockchain transaction policy rules may include any of the following: requesting and / or receiving the one or more blockchain transaction policy rules from the one or more sources.

[0170] In at least various embodiments of the sixth method, the method may include determining whether to send the BCTI based on at least one of the one or more blockchain transaction policy rules.

[0171] In at least various embodiments of the sixth method, the method may include determining, based on at least one of the one or more blockchain transaction policy rules, an indicator / locator that provides information associated with the blockchain transaction in or using the BCTI and / or is used to obtain information associated with the blockchain transaction.

[0172] In at least various embodiments of the sixth method, the BTM can be deployed in any of a RAN node, a CN node, a server, a gateway, and a WTRU. In at least various embodiments of the sixth method, the BTM can be a control plane network function. In at least various embodiments of the sixth method, the device can be any of a RAN node, a CN node, a server, a gateway, and a WTRU. In at least various embodiments of the sixth method, the device can include one or more entities configured to perform various embodiments of the sixth method, and these entities can be any of a Blockchain Client Application (BCA), a Blockchain Transaction Client (BTC), and a Blockchain Network Application (BNA).

[0173] In at least various embodiments of the sixth method, the BNA may be implemented as an application function (AF) or combined with an application function. In at least various embodiments of the sixth method, the BTM may be deployed in the device. In at least various embodiments of the sixth method, the second entity may be a DPP. In at least various embodiments of the sixth method, the BCTI request may include any of the following: an address of a blockchain node (BCN), a type or category of the transaction to be constructed, a maximum transaction construction time, a maximum transaction wait time, a blockchain transaction construction priority, a blockchain transaction inclusion priority, an application category of the requester, and an identifier of the requester.

[0174] The devices are those configured to perform a method such as at least one of the aforementioned methods (which may include any of a receiver, transmitter, processor, and memory). [Representative Use Cases] [1–] [Connected Vehicles]

[0175] Figure 11 illustrates an example use case of the Internet of Vehicles (IoV). Each vehicle may have a wireless connection (e.g., 5G) to the Internet via at least a roadside unit (RSU) (or base station). The RSU may include or have access to a local edge network with computing and storage resources.

[0176] A vehicle can move from one RSU to another. A vehicle can communicate with other vehicles, RSUs, edge networks, core networks, and / or application servers. For example, vehicle 1 can discover vehicle 2 and find that both are under the same RSU 1. Vehicle 1 and vehicle 2 can communicate directly (e.g., vehicle-to-vehicle). After direct communication, vehicle 1, vehicle 2, and / or 5GS may need to maintain a record of their network communications to preserve history. Vehicle 2 can move out of the coverage area of ​​RSU 1 and / or can be associated with a new RSU (RSU 2). Vehicle 2 can communicate with either the CN or network applications via RSU 2.

[0177] In this use case, there are various scenarios where blockchain transactions can be constructed and stored on a specified blockchain. Examples of these scenarios may include any of the following. • Events where vehicles 1 and 2 meet under the same RSU1 can be recorded in a blockchain transaction, which may include, for example, the location information of the two vehicles. Direct communication between vehicle 1 and vehicle 2 can be coordinated and enabled through a decentralized blockchain system. • The communication between vehicle 1 and vehicle 2 can be recorded in a blockchain transaction. This blockchain transaction may include, for example, the duration of the communication and the total amount of data. • When vehicle 2 moves from RSU1 to RSU2, the new location of vehicle 2 can be recorded in the blockchain system. • RSU1 can store the background information of vehicle 2 in the blockchain system. In this way, when vehicle 2 moves from RSU1 to RSU2, RSU2 can directly access the background information of vehicle 2 from the blockchain system without touching RSU1. • Platooning events involving multiple vehicles can be recorded in blockchain transactions. An example of a platooning scenario with three vehicles is shown in Figure 11: vehicle 3, vehicle 4, and vehicle 5. [3.2] [Usage Scenarios] [2 –] [Smart Manufacturing and Logistics]

[0178] Figure 12 illustrates a smart manufacturing and logistics use case. For ease of explanation and simplicity, the component symbols accompanying Figure 12 are prefixed with "12:" in this disclosure. A smart manufacturing and logistics use case may involve four parties: the customer, the e-commerce company, the manufacturer, and the logistics company. These four parties may use Internet of Things (IoT) and / or 5G technologies to implement smart manufacturing and logistics processes. Smart manufacturing and logistics processes may include any of the following: • Step or Operation 1: All parties can log in to 5GS (or the cloud system) as an application. [(12:1)] . • Step or Operation 2: Customers can submit purchase requests to the e-commerce platform (the e-commerce company's application). [(12:2)] . For simplicity, purchase requests can be made for a single product item. • Step or Operation 3: The manufacturer's application can receive a list of product items ordered by the customer. [(12:3)] , possibly from an e-commerce platform. • Step or Operation 4: The manufacturer application can send the list to the factory, where the ordered products will be manufactured and ready for shipment to the customer. [(12:4)] . • Step or Operation 5: The logistics company can receive notification to pick up manufactured items from the factory and transport them toward the customer. [(12:5)] . • Step or operation 6: The item is transported to the warehouse. [(12:6)] , which may be owned or leased by a logistics company. • Step or operation 7: Items can be sent for delivery along the route toward the customer. [(12:7)] . Step 8: The project is accessible and received by the customer. [(12:8)] . • Step or operation 9: The e-commerce platform can receive notifications. [(12:9)] .

[0179] In this scenario, each step or operation can trigger one or more actions by the corresponding party, and any of such events (e.g., each) can be constructed into a blockchain transaction and stored on a designated blockchain. However, the WTRUs attached to each encapsulation may be highly resource-constrained in order to reduce costs. WTRUs may not have the ability to construct transactions and / or participate in a blockchain system (e.g., to store on the blockchain, to execute consensus mechanisms, etc.). As used herein, the term "step" is understood to encompass "one or more operations," and therefore, for ease of explanation and simplicity, the terms "step" and "(multiple) operations" are used interchangeably herein.

[0180] The embodiments address the following key issues related to the use cases described herein.

[0181] Key Issue #1 – The blockchain system and 5GS are two separate systems that are currently not well integrated, making it inefficient and challenging to add 5GS-related data to the blockchain. WTRUs can directly generate transactions containing some data and send these transactions to the blockchain network using an over-the-top method. However, WTRUs are not independent entities but are controlled, managed, and serviced by 5G network functions. On the one hand, WTRUs themselves may not be able to make reasonable decisions about whether to send their data to the blockchain network, as this decision may be monitored by 5G network functions (such as PCF). On the other hand, transactions to be added to the blockchain may include shared information from multiple WTRUs, RAN nodes, and the 5G core network. As a result, the over-the-top method cannot operate efficiently for WTRUs.

[0182] Key Issue #2 – Machine-Type Communication (MTC) devices in 5GS typically have limited resources, and maintaining the entire blockchain or participating in consensus procedures is infeasible (and in some cases impossible) for them. Limited resources do not allow MTC devices to directly participate in the blockchain system. If an MTC device needs to build transactions into the blockchain system, new features (such as blockchain application enablement as disclosed in this paper) can be used to assist the MTC in interacting with the blockchain system, including, for example, building blockchain transactions into the blockchain system.

[0183] Key Issue #3 – Due to the broadcast nature of P2P networks used by blockchain systems, transaction building and block generation will generate high traffic in 5GS, known as blockchain traffic, especially when a large number of MTC devices attempt to build transactions onto the blockchain or when WTRU acts as a BCN directly participating in the blockchain network. This type of blockchain traffic needs to be properly regulated.

[0184] Key Issue #4 – An event to be added to the blockchain may be related to multiple WTRUs (e.g., vehicles in a V2X vertical application). When a blockchain transaction for this event is generated, these WTRUs need to be coordinated.

[0185] Key Issue #5 – Malicious WTRUs could attempt to generate numerous useless transactions into the blockchain system, potentially harming not only the blockchain but also causing congestion in 5GS. Effective authentication and authorization should be provided for transaction construction.

[0186] Key Issue #6 – Blockchain applications may need to include selective transactions in new blocks, for example, to avoid long wait times for transactions to be successfully included in a block. Blockchain applications could directly notify the corresponding blockchain system of such requests each time a new transaction is constructed, but this approach can result in high overhead costs on the blockchain application side.

[0187] Key Issue #7 – Blockchain applications may need to store data across multiple independent or dependent blockchains. While blockchain applications can store data individually on each independent blockchain, this approach can introduce a high burden to the application. [Representative Integrated Blockchain and Wireless System Architecture]

[0188] Figure 13 illustrates an integrated blockchain and wireless system architecture. The integrated blockchain and wireless system architecture may include the following logical layers.

[0189] Device Layer: The device layer can include end devices that support various applications, such as device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, and smart manufacturing and logistics (SML). Additionally, some powerful devices can be participants in a blockchain network (BNWK), such as miners in the Bitcoin system.

[0190] Access Layer: The access layer (such as 5G and outside of RAN or satellite) provides connectivity to end devices. This layer may include distributed edge networks, which can host any of local storage, local computing, and local applications.

[0191] Blockchain Infrastructure Layer: This layer may include different blockchain networks. Each blockchain network may have different protocols and / or support different types of blockchains. A blockchain network may have a set of BCNs. As participants in the blockchain network, each BCN may have storage and computing resources and may maintain a local copy of the complete blockchain (i.e., the ledger). All BCNs of the blockchain network logically form a P2P overlay network to broadcast new transactions and blocks among them.

[0192] Network Function Layer: This layer provides various network functions, such as 5G core network functions, transaction-related blockchain functions, and other traditional network functions. The BCN can utilize these network functions. Furthermore, the blockchain function can interact with the 5G core network function and other network functions to better serve and / or manage the BCN. The blockchain function can operate to connect the blockchain system and the wireless system; for example, the 5G core network function can access the BCN and thus access the complete blockchain via the blockchain function.

[0193] Application Layer: Various network applications can use network functions to access the blockchain network. Devices and network applications can interact with each other via network functions and the blockchain network. [Representative Blockchain Transaction Management Architecture]

[0194] Figure 14 illustrates a functional architecture 1400 for blockchain transaction management. Blockchain transaction management may include blockchain transaction construction, blockchain transaction querying, blockchain transaction subscription, and blockchain transaction access control. Functional architecture 1400 may include BTM 140-1, BCN 141, BTC 142, BCA 143, BNA 144, DPP 145, and EDS 146. Although only a single BCN, single BTC, single BCA, single BNA, single DPP, or single EDS is shown in Figure 14, functional architecture 1400 may include more than one of each. Furthermore, although two BTMs are shown in Figure 14, functional architecture 1400 may include more or fewer BTMs. For simplicity of explanation, BTM 140-1 may be referred to as BTM 140.

[0195] BTM 140 plays a crucial role in the overall architecture. BTM 140 interfaces with BCN 141 and the underlying blockchain network (not shown). BTM 140 receives input data from BNA 144 and / or BCA / BTC 143 / 142, and optionally other input data from DPP 145. BTM 140 generates transactions based on the selected BCN 141. BTM 140 can send transactions to the selected BCN 141. In some cases, BTM 140 can split input data into two parts: one part to be stored in the blockchain network via BCN 140, and the second part to be stored in EDS 146. There may be situations where BNA 144 and / or BCA / BTC 143 / 142 do not directly send data to BTM 140, and can indicate the type and address of data that BTM 140 can retrieve from DPP 145. BTM 140 may send retrieved data to BCN 141 in the form of (multiple) blockchain transactions. BTM 140 may, for example, select and / or assign one or more appropriate BCNs and corresponding blockchain systems for other entities based on instructions or requests from other entities (e.g., BCA, BTC, and / or BNA). BTM 140 may maintain such assigned BCNs for these entities; thus, these entities may not need to explicitly indicate the BCN each time they request BTM 140 to request new transactions for them. This approach reduces signaling indirect costs between BTM 140 and such entities and simplifies operations at the entity level.

[0196] BCN 141 behaves like a regular blockchain node in a blockchain network and supports corresponding blockchain protocols (e.g., transaction formats, blockchain structure, consensus protocols, etc.). BCN 141 is responsible for sending any transactions from BTM 140 to the blockchain network in which BCN 141 participates. After a transaction has been successfully inserted into the blockchain, BCN 141 can send a notification back to BTM 140. BTM 140 can then send requests to BCN 141 to query, discover, and / or retrieve any existing transactions on the blockchain.

[0197] BTC 142 may send data to BTM 140 on behalf of one or more BCAs to be added to a designated blockchain. Alternatively, BTC 142 may indicate the type and / or address (not the data itself) of the data to BTM 140, and BTM 140 may retrieve the data and add it to the designated blockchain. BTC 142 may use transaction management functionality provided by BTM 140.

[0198] BCA 143 can be used as a client application and can log in to BTC 142. BCA 143 can interact with BTC 142. Alternatively, BCA 143 can discover available BTMs (e.g., BTM 140) via BTC and can communicate directly with BTMs to add data to the blockchain.

[0199] As an application, BNA 144 can be similar to BCA 143. BNA 144 can communicate directly with BTM 140 to add data to the blockchain. BNA 144 can be a server-side application entity for a specific blockchain application (e.g., a blockchain-based V2X application, a blockchain-based SML application, etc.) and can interact with zero or more (a group of) BCAs, which can be client-side application entities for the same blockchain application. As an example, for a blockchain-based V2X application, while each vehicle hosts BCA 143, there may be one BNA 144 residing in the cloud or 5GS.

[0200] DPP 145 can provide data to be added to the blockchain and / or policies related to accessing that data and / or accessing the blockchain network via BCN 141. For example, BTM 140 can retrieve data from DPP 145 based on instructions from BNA 144 and / or BTC / BCA 142 / 143. When BNA 144 and / or BTC / BCA 142 / 143 request BTM 140 to add data to the blockchain, BTM can use DPP 144 to check any policies used for that request and / or obtain any policies used for that request from DPP 144. If any policies exist, BTM 140 can enforce them.

[0201] In some scenarios, BNA 144 and / or BTC / BCA 142 / 143 may require or desire BTM 140 to store at least a portion of the data on the blockchain and / or to store at least a portion of the data (e.g., the same or different portions) on an external repository. In this scenario, BTM 140 can access EDS 146 to store the data, thus enabling the hash of the externally stored data to be stored on the blockchain.

[0202] Figure 15 illustrates an instance architecture 1500 for enabling wireless applications using blockchain. Except as described herein, the instance architecture 1500 of Figure 15 is similar to the instance architecture 1400 of Figure 14. BTC 142 can discover BCN 141 from BTM 140, or BTM 140 can assign BCN 141 to BTC 142. Upon learning of BCN 141, BTC 142 can interact directly with BCN 141. For example, BTC 142, representing one or more BCA 143s, can send data from BCA 143 to BCN 141 and / or request BCN 141 to store that data on a blockchain supported by BCN 141. BNA 144 can discover BCN 141 from BTM 140, or BTM 140 can assign BCN 141 to BNA 144. Upon learning of BCN 141, BNA 141 can interact directly with BCN 141. For example, BNA 144 can send its data to BCN 141 and / or request BCN 141 to store the data on a BCN-supported blockchain. [Representative Transactions and Block Construction] [Representative Subject] [BTM] [Controlled Transaction Construction]

[0203] In a transaction construction controlled by BTM, all requests for constructing a blockchain transaction can be sent to BTM. BTM can be responsible for authenticating requests, processing requests by obtaining any additional information, selecting the BCN of a specified blockchain network, and / or forwarding processed requests to the BCN. BCN can construct the requested blockchain transaction and / or send it to the specified blockchain network. BTM can interact with the BCN and the specified blockchain network representing other entities such as BCA, BTC, and / or BNA. Examples of BTM-controlled transaction constructions include (i) BCA / BNA-triggered BTM-controlled transaction constructions, (ii) BTC-triggered BTM-controlled transaction constructions, and (iii) BNA-subscribed BTM-controlled transaction constructions.

[0204] BCA / BNA-triggered BTM-controlled transaction construction is suitable for scenarios where BCA and / or BNA can request and / or trigger BTM to construct blockchain transactions. BTC-triggered BTM-controlled transaction construction is suitable for scenarios where BTC can request and / or trigger BTM to construct blockchain transactions. BNA-subscribed BTM-controlled transaction construction is suitable for scenarios where (i) one or more entities (e.g., BCA, BTC, and / or BTM) can disclose one or more subscribing events that trigger BTM to construct blockchain transactions, facilitate the construction of blockchain transactions, and / or facilitate the storage of information in EDS, and (ii) BNA subscribes to one or more events disclosed by such entities. [Representative] [BCA / BNA] [The triggered victim] [BTM] [Controlled Transaction Construction]

[0205] Figure 16 illustrates program 1600 for constructing BTM-controlled transactions triggered by BCA / BNA. For ease of explanation and simplicity, program 1600 is described with reference to transaction management architecture 1400 (Figure 14) and communication system 100 (Figures 1 and 5). Program 1600 can also be implemented using different architectures. Program 1600 is suitable for scenarios where BCA 143 and / or BNA 144 can send (publish) requests to add information to the blockchain via BTM 140.

[0206] The term "step" used in this disclosure (together with the remainder of this disclosure) with respect to Figures 16 to 26 and 29 to 36 shall be understood to encompass "one or more operations," and the terms "step" and "(multiple) operations" are used interchangeably herein. The element symbols for the accompanying operations described with respect to Figures 16 to 26 and 29 to 36 in this disclosure may include a prefix consisting of a figure number and a colon.

[0207] Preprocessing: BCA 143 can log in to or be associated with BTC 142. BTC 142 can log in to or be associated with BTM 140. BTM 140 has the address of BCN 141 and can communicate with it via provision and / or configuration. BCN 141 is a participant in the designated blockchain system and maintains the designated blockchain (or decentralized ledger). BNA 144 can log in to or be associated with BTM 140. Optionally, DPP 145 and EDS 146 may exist that are accessible to BTM 140. BCA 143 can be provided and / or configured to use the functionality provided by BTC 142. BTC 142 can be provided and / or configured to access the functionality of BTM 140. BTM 140 can be provided and / or configured to interact with the designated blockchain system via BCN 141. BTM 140 can be provided and / or configured to interact with a designated blockchain system on behalf of BTC 142 and / or BCA 143. BCA 143 and BTC 142 can be co-located within the same device (e.g., smartphone, vehicle, drone, sensor) or hosted by two different devices. As a function, BTM 140 can reside (be configured) in devices, gateways, edge network components, 5G core network components, and / or data center components. BCN 141 as a function can reside (be configured) in devices, gateways, edge network components, 5G core network components, and / or data center components.

[0208] Prior to step 1, when requesting to add information to the blockchain is made in steps 1 and 3 (or step 3'), BTM 140 may have notified BCA 143 and / or BTC 142 (or BNA 144) to send one or more parameters (e.g., a list of parameters) ("transaction construction parameters") to BTM 140. BCA 143 and / or BTC 142 (or BNA 144) may include a set of transaction construction parameters ("transaction construction parameter set") in the request sent by BCA 143 in step 1 and / or in the request sent by BTC 142 in step 3 (or in the request sent by BNA 144 in step 3').

[0209] Alternatively (and / or additionally), BTM 140 may construct and assign transaction descriptions for each or both of BCA 143 and BTC 142 (or BNA 144). The transaction description (or each transaction description) may describe the transaction construction parameters to be included in the new transaction, how the new transaction should (or can) be constructed, to which entities the transaction description can be applied, and / or other information. BCA 143 and BTC 142 (or BNA) may include information indicating the applicable transaction descriptions in the requests sent in steps 1 and 3 respectively (or sent via step 3' of BNA 144). Accordingly, BTM 140 should (or may) use (multiple) transaction descriptions to construct a new transaction for BCA 143 and / or BTC 142 (or BNA 144). Alternatively (and / optionally), after step 3 (or step 3'), BTM 140 may select a transaction description for BCA 143 and BTC 142 (or BNA 144) or for each of BCA 143 and BTC 142 (or BNA 144). BTM 140 may use (multiple) transaction descriptions to construct new transactions for BCA 143 and / or BTC 142 (or BNA 144). This method simplifies and lightens the operation for BCA 143 and / or BTC 142 (or BNA 144).

[0210] Step 1 [:] BCA 143 can generate and send the first request to add information to the blockchain to BTC 142. [(16:1)] BTC 142 (or BTM 140) may have installed one or more blockchain policy rules to BCA 143. BCA 143 may generate a first request based on the installed blockchain policy rules. For example, the blockchain policy rules may command BCA 143 to generate this request every T1 seconds. When the first request is generated, BCA 143 may include information indicating the appropriate transaction instructions and / or transaction construction parameter sets in the first request. The transaction construction parameter sets may include any of the following transaction construction parameters: (i) the number of transactions to be constructed, (ii) the application category of BCA 143, (iii) the identifier of BCA 143, (iv) the application name of BCA 143, (v) the security credential information of BCA 143 (e.g., the digital signature of BCA 143 applied to the request (or each request), and (vi) the content of each transaction. The content of each transaction may include the following parameters: • The address and / or identifier of the BCN participating in the designated blockchain system; • Category of transactions to be built: BTM and / or BCN can use this parameter to group pending transactions of the same category to build a new block, or to select transactions of different categories when building a new block for balancing purposes. Including transactions of the same type in a block will make it more efficient to query or retrieve specific categories of transactions later; • Maximum Transaction Build Time: This parameter indicates the deadline by which the requested transaction should be built; • Maximum Transaction Waiting Time: This parameter indicates the duration a transaction can wait before being included in a new block. In other words, once a transaction is constructed, it should (can) be included in a new block without waiting longer than the lifecycle indicated by this parameter. BCN 141 and other BCNs can use this parameter to influence how a transaction is forwarded within the blockchain network and how it will (can) be selected for inclusion in a new block. Transactions with shorter transaction waiting times will likely be forwarded faster and selected earlier; • Transaction Build Priority: This parameter indicates the importance and / or potential time requirement of building the transaction. For example, transaction build priority can indicate a high importance requirement or low potential time requirement for building a transaction, so that the transaction is built and / or sent to the blockchain network faster than requests indicating a lower transaction build priority; • Transaction inclusion priority: This parameter indicates the reward and / or potential time requirement for including a transaction in a new block. For example, transaction inclusion priority can indicate a lower potential time requirement or a higher reward to allow the transaction to be included in the new block earlier; • First information (“Information 1”) and / or the address where Information 1 is stored; Information 1 may be added to a designated blockchain; • Second information ("Information 2") and / or the address where Information 2 is stored; Information 2 may not be added to the designated blockchain, but its hash value may be added to the designated blockchain; • The address of the additional data will be added to the designated blockchain along with information 1; and / or • The address of the recipient of the transaction should be received, known, and / or notified. The recipient may be another BCA, another BNA, and / or another BTC.

[0211] Step 2: BTC 142 can receive the first request BCA 143. BTC 142 can authenticate and authorize the first request using background and / or security credential information of BCA 143 that BTC 142 can maintain locally (e.g., the public key of BCA 143). If the first request is authenticated, BTC 142 can buffer the first request and / or aggregate the first request with one or more other requests to add information to the blockchain. [(16:2)]. Other requests may come from the same BCA 143 and / or one or more other BCAs. BTC 142 may (i) receive all other requests before or after receiving the first request, or (ii) receive some other requests before or after receiving the first request. If authentication fails, BTC 142 may discard the first request and may skip all remaining steps except step 13.

[0212] Step 3: BTC 142 can send the first request, or a first request that will be aggregated with other requests, to BTM 140. [(16:3)] For ease of explanation and simplicity, the first request aggregated with other requests may be referred to as the "first request". BTM 140 may have installed one or more blockchain policy rules to BTC 142. BTC 142 may generate the first request based on the installed blockchain policy rules. For example, the blockchain policy rules may command BTC 142 to send this request at a rate below the threshold. The first request sent by BTC 142 may include (i) the same transaction construction parameters disclosed above in step 1, and (ii) one or more additional transaction construction parameters. If the set of transaction construction parameters disclosed above in step 1 is not included in the first request received from BCA 143, BTC 142 may append them to the first request before forwarding it to BTM 140. Additional transaction construction parameters may include any of the following: (i) identifiers that can be used and executed by BTM 140 to regulate whether / how information and additional data can be added to a specified blockchain; (ii) BCNs that can be inferred from them. The type, address, or identifier of the blockchain specified at address 141; (iii) the identifier of BTC 142; (iv) a hash function or any associated key that can be used by BTM 140 to hash the data to be stored in EDS 146 (in step 8); (v) a trigger or instruction that can require BTM 140 to periodically obtain data from a specified location and store such data on a specified blockchain; and / or (vi) security credential information of BTC 142 (e.g., a requested digital signature).

[0213] Step 3': BNA 144 can send a second request to BTM 140 to add information and data to the blockchain. [(16:3')] . BTM 140 may have installed one or more blockchain policy rules to BNA 144. BNA 144 may generate a second request based on the installed blockchain policy rules. For example, the blockchain policy rules may command BNA 144 to generate this request at most every T2 seconds. The second request may include (i) a set of transaction creation parameters, (ii) additional transaction creation parameters, and (iii) one or more of the following transaction creation parameters ("other transaction-creation parameter"): (i) an identifier of BNA 141; and / or (ii) security credential information of BCA 143 (e.g., the digital signature of this request).

[0214] Step 4: BTM 140 can send a third request to DPP 145 to review any applicable blockchain policies and rules, as well as any additional information. [(16:4)] . In various embodiments, BTM 140 may have been configured with one or more blockchain policy rules via DPP 145, and may have automatically stored one or more blockchain policy rules. BTM 140 may use locally available blockchain policy rules before requesting and / or retrieving any from DPP 146.

[0215] For example, the identifier of a blockchain policy rule may be included in one or more of the first request from BTC 142 (step 3) and / or the second request from BNA 144 (step 3'). BTM 140 may submit this identifier to DPP 145 to retrieve the contents of the corresponding blockchain policy rule. The blockchain policy rule may specify: 1) the type, address, and / or identifier of the specified blockchain to be applied to one or more of the requests from BNA 144, BTC 142, and / or BCA 143; 2) whether there is any additional information to be added to the specified blockchain along with any specified information; and 3) where such additional information is retrieved if not provided by DPP 145.

[0216] In another instance, one or more of the first request from BTC 142 and / or the second request from BNA 144 may include the address of its self-retrieval of additional data. BTM 140 may use this address to retrieve additional data from DPP 145.

[0217] In another instance, one or more of the first request from BTC 142 and / or the second request from BNA 144 may not include any information content, but may include the address of information to be added to the designated blockchain. BTM 140 can use this address to retrieve the information from DPP 145.

[0218] In another instance, BTM 140 may submit the identifier of BTC 143, the identifier of BCA 142, and / or the identifier of BNA 144 to DPP 145 to retrieve any relevant blockchain policy rules and additional information.

[0219] Step 5: DPP 145 can send the first response to BTM 140. [(16:5)]. The first response may include the content of the blockchain policy rule, information to be added to the designated blockchain, and / or additional data to be added to the designated blockchain along with the information to be added. Additionally, whenever a blockchain policy rule is retrieved, BTM 140 may store it locally for future use, avoiding future retrievals of DPP 145 that may be instructed or commanded by DPP 145, or the costs associated with such future retrievals. DPP 145 may instruct BTM 140 that the blockchain policy rule returned may or should be stored locally. Step 6: Based on the first response from DPP 145 and one or more of the first and / or second requests from BTC 142 and / or BNA 144, BTM 140 may determine the data to be added to the designated blockchain (referred to as data1) and the data to be stored in EDS 146 (referred to as data2). [(16:6)] . If there is no need to store any data in EDS 146, steps 8 and 9 can be skipped.

[0220] Before (but after step 5), BTM 140 has access to the auditor (e.g., another BTM, another BTC, another BCA, another BNA, or a third party (such as 5G core network functionality)) to obtain confirmation or any more additional information from the auditor. For example, if BCA 143 issues the first request and the BCA is managed by another BNA of the same blockchain application, the auditor may be this other BNA. BTM 140 can send a fourth request to the auditor. The fourth request may include some or complete information as included in the first request from BTC 142 and / or the second request from BNA 144 . The fourth request may include an identifier of BTM 140, a security token (e.g., a note, its certificate or signature) relating to BCA / BTC 143 / 142 or BNA 144, and / or the type and address of additional information to be retrieved. Based on the assessment of all the information as included in the fourth request, the auditor may authorize the request. If the authorization is approved, the auditor may send the first confirmation response to BTM 140 . The first confirmation response may include additional information from the auditor (assuming BTM 140 has requested it). If the authorization fails, the auditor may send a denial response to BTM 140 . Response In rejection response, BTM may not perform step 6 and the remaining steps. After receiving the first acknowledgment response from the auditor, the BTM 140 may proceed with the procedure 1600 .

[0221] Step 7: BTM 140 may select the specified blockchain and the BCN 141 used for that specified blockchain [(16:7)] . If BTM 140 has been provided or configured to have a specified blockchain and BCN 141 , this step may be skipped or BTM 140 may again select the specified blockchain and the BCN 141 used for that specified blockchain.

[0222] In one embodiment, the blockchain policy rule (e.g., as retrieved from DPP 144 in step 4 and / or step 5) may include the specified blockchain and the corresponding BCN 141 . Thus, this step may be skipped or BTM 140 may again select any of the specified blockchain and the BCN 141 used for that specified blockchain. In addition, this step may also be skipped if one or more of the first request and / or the second request from BTC 142 and / or from BNA 144 instruct the specified blockchain and corresponding BCN 141 .

[0223] BTM 140 may perform such BCN selection for BCA 143 and / or BNA 144 only once, and may locally maintain information indicating the selected BCN for BCA 143 or BNA 144. This locally maintained information indicating the selected BCN for BCA 143 or BNA 144 may be used by BTM 140 when receiving subsequent requests from BCA 143 or BNA 144 to construct a transaction. Alternatively, during the system setup and configuration phase, BTM 140 may have already selected and assigned one or more BCNs for BCA 143 or BNA 144 based on one or more instructions and / or requests from BCA 143 or BNA 144. Thus, step 7 need not be performed, and the first and / or second requests from BCA 143 (step 1) and / or the request from BNA 144 (step 3') need not include or indicate BCN information.

[0224] Step 8: BTM 140 can send data2 to EDS 146 and can command EDS 146 to store data2. [(16:8)] .

[0225] Step 9: EDS 146 stores data2. EDS 146 can then send the second response to BTM 140. [(16:9)]. The second response may include the address from which it retrieves data2.

[0226] Step 10: BTM 140 can send the hash ("hash(data2)") of data1 and data2 to BCN 141, which requests that data1 and hash(data2) be stored in the specified blockchain. [(16:10)]. BTM 140 may use any additional hash-related information included in one or more of the first and / or second requests from BCA 143 and / or BNA 144 or from blockchain policy rules to calculate hash(data2). If data2 is not proposed or required due to step 6, BTM 140 will (may) not calculate hash(data2), but may send (e.g., only send) data1 to BCN 141. If data1 is not proposed or required due to step 6, BTM 140 may send (e.g., only send) hash(data2) to BCN 141.

[0227] Step 11: BCN 141 can send the third response to BTM 140. [(16:11)] . The third response may be an immediate response confirming receipt of data1, hash(data2), and / or the request from BTM 140, and / or indicating that the requested blockchain transaction has been constructed (but not yet confirmed within the blockchain network). This step may be optional.

[0228] Step 12: BTM 140 may send a fourth response to BTC 142 indicating whether the requested information has been constructed in a blockchain transaction (but not yet confirmed within the blockchain network) and / or stored in EDS 146. [(16:12)] .

[0229] Step 13: BTC 142 can forward the fourth response to BCA 143 [(16:13)] .

[0230] Step 14: BCN 141 can execute a specified blockchain protocol to store data1 and / or hash(data2) into a specified blockchain. [(16:14)] For example, BCN 141 can generate blockchain transactions that include data1 and / or hash(data2). BCN 141 can send blockchain transactions to a designated blockchain network.

[0231] Step 15: After the blockchain transaction, including data1 and / or hash(data2), has been successfully added to the designated blockchain, BCN 141 may send a notification to BTM 140. In one embodiment, the transaction may have a transaction number TranNumX, and it may be included in a block with a sequence number equal to BlockNumY. One or more of the first and / or second requests from BCA 143 and / or BNA 144 may include a recipient (BCA, BTC, or BNA). The recipient may connect to another BTM (“BTM-X”) (not shown). BTM-X may interact with another BCN (“BCN-X”) participating in the same blockchain system as BCN 141. Because the transaction propagates through the blockchain system, BCN-X should (can) receive the transaction. BCN-X may send the transaction to BTM-X. BTM-X may forward the transaction to the recipient.

[0232] Step 16: Optionally, BTM 140 may send a fifth request to update EDS 146 using the block sequence number (e.g., BlockNumY) and / or transaction sequence number (e.g., TranNumX). [(16:16)] . EDS 146 can associate the block sequence number (e.g., BlockNumY) and / or the transaction sequence number (e.g., TranNumX) with data2 previously stored in EDS 146. If data2 was not previously stored in EDS 146, step 16 should (may) be skipped.

[0233] Step 17: BTM 140 can send the second confirmation response to BTC 142. [(16:17)] This response may include the address of data2 stored in EDS 146, hash(data2), block sequence number (e.g., BlockNumY), and / or transaction sequence number (e.g., TranNumX). If BCA 143 is managed by one or more BNAs of the same blockchain application other than BNA 144 (“BNA-X”), BTM 140 may send the same second confirmation to BNA-X.

[0234] Step 17': If BTM 140 receives a second request from BNA 144 (Step 3') or if BNA 144 manages BCA 142, BTM 140 may send a third confirmation response to BNA 144. [(16:17')] The third confirmation response may include the address of data2 stored in EDS 146, hash(data2), block sequence number (e.g., BlockNumY), and / or transaction sequence number (e.g., TranNumX).

[0235] Step 18: BTC 142 may forward the third confirmation response received from BTM 140 to BCA 143.

[0236] Program 1600 can be used to support, but is not limited to, the following scenarios: Scenario 1: The requester can send data3 to BTM and request BTM to store data3 in a specified blockchain. BTM can store data3 in the specified blockchain via BCN. The requester can be BCA, BTC, or BNA. • Scenario 2: The requester can send data4 and data5 to BTM. BTM can store data4 in the designated blockchain via BCN, and store data5 in EDS. The requester can be BCA, BTC, or BNA. • Scenario 3: The requester can send the addresses of data6 and data7 to BTM. BTM can retrieve data7 from DPP. BTM can store data6 in the designated blockchain and data7 in EDS. The requester can be BCA, BTC, or BNA. Scenario 4: The requester can send the addresses of data8 and data9 to BTM. BTM can retrieve data9 from DPP. BTM can store data9 in the designated blockchain and data8 in EDS. The requester can be BCA, BTC, or BNA. Scenario 5: The requester can send the addresses of data10 and data11 to BTM. BTM can retrieve data11 from DPP. BTM can then store both data10 and data11 in a designated blockchain. The requester can be BCA, BTC, or BNA. Scenario 6: The requester can send the address of data12 to BTM. BTM can retrieve data12 from DPP. BTM can then store data12 in a specified blockchain. The requester can be BCA, BTC, or BNA. • Scenario 7: The requester can send the addresses of data13 and data14 to BTM. BTM can retrieve data13 and data14 from DPP. BTM can store data13 in the specified blockchain and data14 in EDS. The requester can be BCA, BTC, or BNA. • Scenario 8: The requester can send an event notification to BTM. BTM can use the event notification to locate blockchain policy rules (from locally stored blockchain policy rules or retrieved from DPP). BTM can retrieve any requested information and add it to the specified blockchain as described and specified by both the event notification and the blockchain policy rule. The requester can be BCA, BTC, or BNA. [Representative] [BTC] [The triggered victim] [BTM] [Controlled Transaction Construction]

[0237] In various embodiments, BTC can manage one or more BCAs. BTC can monitor the state of the BCAs and can proactively decide and request BTM to construct new transactions for one or more BCAs based on their individual states without any explicit request or instruction from the corresponding BCA. In various embodiments, BTC can request BTM to construct transactions to store its current state or specific events to the blockchain. For example, when a specific BCA or a specific type of BCA logs into BTC, BTC can request BTM to construct transactions to record such BCA logins.

[0238] Figure 17 illustrates a procedure 1700 for constructing a BTM-controlled transaction triggered by BTC. For ease of explanation and simplicity, procedure 1700 is described with reference to transaction management architecture 1400 (Figure 14) and communication system 100 (Figures 1 and 5). Procedure 1700 can also be implemented using different architectures. Procedure 1700 is suitable for scenarios where a first BTC 142-1 can request information to be added to the blockchain via BTM 140, and can involve multiple BTC (such as a second BTC 142-2).

[0239] Preprocessing: BTC 142-1 and BTC 142-2 can log in to or associate with BTM 140. BTM 140 has the address of BCN 141 and can communicate with it. BCN is a participating node in the designated blockchain system and maintains the designated blockchain (or decentralized ledger). Optionally, DPP 144 and EDS 146 may exist that BTM 146 can access. BTC 142-1 and BTC 142-2 can access the functionality of BTM 140 by provisioning and / or configuration. BTM 140 can interact with the designated blockchain system via BCN 141 by provisioning and / or configuration. BTM 140 can interact with the designated blockchain system on behalf of BTC 142-1 and 142-2 by provisioning and / or configuration. BTC 142-1 and 142-2 can reside (be configured) in a device (e.g., a smartphone, vehicle, drone, sensor) or individual devices. BTM 140, as a function, can reside (be configured) in a device, gateway, edge network component, 5G core network component, and / or data center component. BCN 141, as a function, can reside (be configured) in a device, gateway, edge network component, 5G core network component, and / or data center component.

[0240] Step 1: BTC 142-1 can receive triggers to add information to the specified blockchain. [(17:1)] . Triggers may be generated by BTC 142-1 based on its local blockchain policy rules or when requested by BCA (not shown) and / or BNA (not shown).

[0241] Step 2: BTC 142-1 can send the first request to add information to the blockchain to BTM 140. [(17:2)] Operations similar to those described in step 3 of procedure 1600 (Figure 16) can also be performed. The first request may include a transaction construction parameter set (as disclosed above), additional transaction construction parameters (as disclosed above), and additional information. The additional information may indicate to BTM 140 that BTM 140 may need to access BTC 142-2. The additional information may include an identifier for BTC 142-1 or any other relevant information that BTM 140 can use to infer the address and / or identifier of BTC 142-1. The additional information and / or request message may include the name, address, and / or identifier of the additional data. BTM 140 may use this additional information to retrieve additional data from BTC 142-2. The additional information and / or request message may include an identifier (BTC group identifier) ​​of a group of BTCs (e.g., BTC 142-1 and BTC 142-2). BTC groups and their corresponding BTC group identifiers can be constructed in BTM 140 by means of BTC group members (e.g., BTC 142 and / or BTC 142-2), and / or by means of other entities / components.

[0242] Step 3: BTM 140 can receive the first request from BTC 142-1. Based on the transaction construction parameter set, additional transaction construction parameters, and additional information, BTM 140 can determine whether to retrieve additional information from BTC 142-2. [(17:3)] . BTM 140 may determine that it may need to contact BTC 142-2 to obtain confirmation or additional information. For example, if a request from BTC 142-1 includes a BTC group identifier that includes BTC 142-1 and 142-2, BTM 140 may determine to contact BTC 142-1 and any other member of the BTC group other than BTC 142-1.

[0243] Step 4: BTM 140 may send a second request to BTC 142-2 to retrieve additional information or obtain confirmation. [(17:4)]. The second request may include an identifier for BTC 142-1; an identifier for BTC 142-2; an identifier for the BTC group including BTC 142-1 and BTC 142-2; and / or the name, address, and / or identifier of any additional data to be retrieved. Alternatively, BTM 140 may retrieve additional data from other locations (e.g., one or more BNAs and / or one or more BCAs).

[0244] Step 5: BTC 142-2 can send the first response to BTM 140 [(17:5)] The first response may include additional information or confirmation.

[0245] Step 6: BTM 140 can be operated to store data in either EDS 146 or the blockchain. [(17:6)] For example, operations similar to those in procedure 1600 starting from step 4 (Figure 16) can be performed via BCN 141 to store selected data in EDS 146 and / or to store other selected data in a designated blockchain.

[0246] Step 7: BTM 140 can send the first notification to BTC 142-1 [(17:7)] . BTM 140 can, for example, perform an operation similar to that represented by step 17 of procedure 1600 (Figure 16).

[0247] Step 8: Optionally, BTM 140 may send a second notification to BTC 142-2 [(17:8)] . [Representative] [BNA] [Subscribed Receivers] [BTM] [Controlled Transaction Construction]

[0248] Figure 18 illustrates a BTM-controlled transaction construction procedure 1800 for BNA subscription. For ease of explanation and simplicity, procedure 1800 is described with reference to transaction management architecture 1400 (Figure 14) and communication system 100 (Figures 1 and 5). Procedure 1800 can also be implemented using different architectures. Procedure 1800 is suitable for scenarios in which (i) one or more entities (e.g., BCA 143, BTC 142, and / or BTM 140) can disclose one or more subscribing events that trigger BTM 140 to construct blockchain transactions, facilitate the construction of blockchain transactions, and / or facilitate the storage of information in EDS, and (ii) BNA 144 can subscribe to one or more events opened by such entities.

[0249] Preprocessing: BCA 143 can log in to or be associated with BTC 142. BTC 142 can log in to or be associated with BTM 140. BTM 140 has the address of BCN 141 and can communicate with it. BCN 141 is a participating node in the designated blockchain system and maintains the designated blockchain (or decentralized ledger). BNA 144 can log in to or be associated with BTM 140. Optionally, DPP 145 and EDS 146 may exist that are accessible to BTM 140. BCA 143 can be provided and / or configured to use the functionality provided by BTC 142. BTC 142 can be provided and / or configured to access the functionality of BTM 140. BTM 140 can be provided and / or configured to interact with the designated blockchain system via BCN 141. BTM 140 can be provided and / or configured to interact with a designated blockchain system on behalf of BCA / BTC 143 / 142. BCA 143 and BTC 142 can be co-located within the same device (e.g., smartphone, vehicle, drone, sensor) or hosted by two different devices. As a function, BTM 140 can reside (be configured) in devices, gateways, edge network components, 5G core network components, and / or data center components. BCN 141 as a function can reside (be configured) in devices, gateways, edge network components, 5G core network components, and / or data center components.

[0250] Step 1: BNA 144 can send a subscription request for the event disclosed by BCA 143 to BTM 140. [(18:1)] . A subscription request may include any of the following parameters: (i) an identifier of BCA 143; BCA 143 may trigger a request to add information to the specified blockchain when an event occurs (detected by BCA 143). (ii) the conditions or event of the subscription; (iii) the specified blockchain; and (iv) an identifier of BNA 144.

[0251] Step 2: BTM 140 can authenticate the subscription request to determine if BNA 144 has the right to subscribe to BCA 143 using the identifiers of BNA 144 and BCA 143. If authentication is successful, BTM 140 can use the identifier of BCA 143 to locate BTC 142. BTM 140 can then send (e.g., forward) the subscription request to BTC 142. [(18:2)] .

[0252] Step 3: BTC 142 can send (e.g., forward) the subscription request to BCA 143 [(18:3)] . BTC 142 can locally maintain one or more parameters from the subscription request.

[0253] Step 4: BCA 143 can handle subscription requests. BCA 143 can send an initial response (e.g., an immediate response) to BTC 142. [(18:4)] .

[0254] Step 5: BTC 143 can send (e.g., forward) the first response to BTM 140 [(18:5)] .

[0255] Step 6: BTM 140 may send (e.g., forward) the first response to BNA 144 [(18:6)] .

[0256] Step 7: The incident occurred at BCA 143 (detected by it). [(18:6)] . The event can trigger BCA 143 to send a request to BTC 142 to add information to the blockchain. [(18:7)], and / or perform other operations similar to those represented by step 1 of procedure 1600 (Figure 16).

[0257] Steps 8 to 25: Operations similar to those shown in steps 2 to 18 of procedure 1600 (Figure 16) can be performed to add specified information to a specified blockchain and / or to EDS 146.

[0258] Step 26: BCA 143 can send the second response to BNA 144. [(18:26)] . The second response may be sent directly to BNA 144, or it may be sent to BTC 142 and then relayed to BNA 144 by BTC 142 and / or BTM 140.

[0259] In one embodiment, after the event occurs (step 7), BCA 143 may send a notification to BNA 144. BNA 144 may decide whether to construct a new transaction. If BNA 144 decides to construct a new traction, it may send a trigger or signal back to BCA 143. BCA 143 may respond to the request from BNA 144 to add information to the blockchain by sending a trigger or signal to BTC 142 and / or perform other operations similar to those represented by step 1 of procedure 1600 (Figure 16). After step 7, steps 8 through 26 may be performed. [Representative Subject] [BTC] [Controlled Transaction Construction]

[0260] In a BTC-controlled transaction construction, all requests for constructing a blockchain transaction are sent to BTC. BTC (optionally assisted by BTM) is responsible for authenticating requests, obtaining any additional information processing requests, selecting the BCN of the designated blockchain network, and forwarding processed requests to the BCN. The BCN can construct the requested blockchain transaction and send it to the designated blockchain network. BTC can interact with the BCN and the designated blockchain network representing other entities (such as BCA and / or another BTC). Examples of BTC-controlled transaction construction include (i) BTC-controlled transaction construction triggered by BCA; and (ii) BTC-controlled transaction construction subscribed to by BTM. BTC-controlled transaction construction triggered by BCA is suitable for scenarios where BCA can request and / or trigger BTC to construct blockchain transactions, facilitate the construction of blockchain transactions, and / or facilitate the storage of information in EDS. BTM subscriptions to BTC-controlled transaction construction can be adapted to (i) scenarios where BTC can reveal one or more subscribing events that trigger BTC to construct blockchain transactions, facilitate the construction of blockchain transactions, and / or facilitate the storage of information in EDS, and (ii) scenarios where BTM subscriptions to one or more events revealed by BTC.

[0261] Figure 19 illustrates a procedure 1900 for constructing BTC-controlled transactions triggered by BCA. For ease of explanation and simplicity, procedure 1900 is described with reference to transaction management architecture 1500 (Figure 15) and communication system 100 (Figures 1 and 5). Procedure 1900 can also be implemented using different architectures. Procedure 1900 is suitable for scenarios where BCA 143 can request and / or trigger BTC 142 to (i) construct blockchain transactions, (ii) facilitate the construction of blockchain transactions, and / or (iii) facilitate the storage of information in EDS 146.

[0262] Preprocessing: BCA 143 can log in to or be associated with BTC 142. BTC 142 can log in to or be associated with BTM 140. BTM 140 has the address of BCN 141 and can communicate with it. BCN 141 is a participating node in the designated blockchain system and maintains the designated blockchain (or decentralized ledger). Optionally, DPP 145 and EDS 146 may exist that are accessible to BTM 140. BCA 143 can be provided and / or configured to use the functionality provided by BTC 142. BTC 142 can be provided and / or configured to access the functionality of BTM 140. BTC 142 can be provided and / or configured to interact with the designated blockchain system via BCN 141. BTC 142 can be provided and / or configured to interact with the designated blockchain system on behalf of BCA 143. BCA 143 and BTC 143 can be co-located within the same device (e.g., smartphone, vehicle, drone, sensor) or hosted by two different devices. BTM 140, as a function, can reside (be configured) in devices, gateways, edge network components, 5G core network components, and / or data center components. BCN 141, as a function, can reside (be configured) in devices, gateways, edge network components, 5G core network components, and / or data center components.

[0263] Step 1: BCA 143 can send the first request to add information to the blockchain to BTC 142. [(19:1)], and / or may perform other operations similar to those represented by step 1 of procedure 1600 (Figure 16).

[0264] Step 2: BTC 142 can receive the first request BCA 143. BTC 142 can authenticate and authorize the first request using background and / or security credential information of BCA 143 that BTC 142 can maintain locally (e.g., the public key of BCA 143). If the first request is authenticated, BTC 142 can buffer the first request and / or aggregate the first request with one or more other requests to add information to the blockchain. [(19:2)]. Other requests may come from the same BCA 143 and / or one or more other BCAs. BTC 142 may (i) receive all other requests before or after receiving the first request, or (ii) receive some other requests before or after receiving the first request. If authentication fails, BTC 142 may discard the first request and may skip all steps except step 13.

[0265] Step 3: BTC 142 can use BTM 140 to check applicable policies, rules, and any additional information. [(19:3)] . Alternatively, BTC 142 can directly use DPP 145 to check policy rules without going to BTM 140 (not shown). If BTC 142 directly uses DPP 145 to check policy rules, steps 4 and 6 can be skipped.

[0266] Step 4: BTM 140 can send (forward) a second request to DPP 145 to check any applicable blockchain policy rules and any additional information. [(19:4)] . In various embodiments, BTM 140 may have been configured with one or more blockchain policy rules via DPP 145, and may have been dynamically stored with one or more blockchain policy rules. BTM 140 may use locally available blockchain policy rules before requesting and / or retrieving any from DPP 146.

[0267] Step 5: DPP 145 can send the first response to BTM 140. [(19:5)]. The first response may include the content of the blockchain policy rule, information to be added to the designated blockchain, and / or additional data to be added to the designated blockchain along with the information to be added. Whenever a blockchain policy rule is retrieved, BTM 140 may store it locally for future use and avoid future retrievals of DPP 145 that may be instructed or commanded by DPP 145 or involve the cost of future retrievals. DPP 145 may instruct BTM 140 whether the blockchain policy rule can or should be stored locally. If DPP 145 receives the first request directly from BTC 142 (step 3), DPP 145 may send the first response directly to BTC 142 (without going through BTM 140).

[0268] Step 6: BTM 140 can forward the first response to BTC 142 [(19:5)] This response may include additional information received by BTM 141 from DPP in step 5 or inserted by the BTM itself.

[0269] Step 7: Based on the first response from DPP 145 and one or more of the first and / or second requests from BCA 143 and / or BNA 144, BTC 142 can determine the data to be added to the designated blockchain (referred to as data1) and the data to be stored in EDS 146 (referred to as data2). [(19:7)] . If there is no need to store any data in EDS 146, steps 9 and 10 can be skipped.

[0270] Step 8: BTC 142 allows you to select a specific blockchain and the BCN 141 used for that blockchain. [(19:8)] . If BTC 142 has been provided or configured with a specified blockchain and BCN 141, this step can be skipped or BTC 142 can select the specified blockchain and BCN 141 for that specified blockchain again.

[0271] In one embodiment, the blockchain policy rule (e.g., retrieved from DPP 144 in steps 4 and / or 5) may include a designated blockchain and its corresponding BCN 141. Thus, this step may be omitted, or BTC 142 may again select any designated blockchain and its BCN 141. Additionally, this step may also be omitted if the first request from BCA 143 specifies a designated blockchain and its corresponding BCN 141.

[0272] BTC 142 may perform such BCN selection for BCA 143 only once and may locally maintain information indicating the selected BCN for BCA 143. This locally maintained information indicating the selected BCN for BCA 143 may be used by BTC 142 when it receives subsequent requests from BCA 143 to construct transactions. Alternatively, during the system setup and configuration phase, BTC 142 may have already selected and assigned one or more BCNs for BCA 143 based on one or more instructions and / or requests from BCA 143. In this case, step 8 need not be performed, and the first request from BCA 143 (step 1) does not need to include or indicate BCN information. Alternatively, BTC 142 may send a request to BTM 140 to discover an appropriate BCN. BTM 140 may have already provided or configured BTC 142 with one or more BCNs (e.g., even before step 1).

[0273] Step 9: BTC 142 can send data2 to EDS 146 and instruct EDS 146 to store data2. [(19:9)] .

[0274] Step 10: EDS 146 stores data2. EDS 146 can then send the second response to BTC 143. [(19:10)] . The second response may include the address from which it retrieves data2.

[0275] Step 11: BTC 142 can send the hash ("hash(data2)") of data1 and data2 to BCN 141, which requests that data1 and hash(data2) be stored in the specified blockchain. [(19:11)] BTC 142 may use any additional hash-related information included in the first request from BCA 143 or from the blockchain policy rules to calculate hash(data2). If data2 is not presented or required due to step 7, BTC 142 may not calculate hash(data2), but may send (e.g., send only) data1 to BCN 141. If data1 is not presented or required due to step 7, BTC 142 may send (e.g., send only) hash(data2) to BCN 141.

[0276] Step 12: BCN 141 can send the third response to BTC 142. [(19:12)] The third response may be an immediate response confirming receipt of data1, hash(data2), and / or the request from BTC 142, and / or indicating that the requested blockchain transaction has been constructed (but not yet confirmed within the blockchain network). This step may be optional.

[0277] Step 13BTC 142 may send a fourth response to BCA 143 indicating whether the requested information has been constructed in a blockchain transaction (but not yet confirmed within the blockchain network) and / or stored in EDS 146. [(19:13)] .

[0278] Step 14: BCN 141 can execute a specified blockchain protocol to store data1 and hash(data2) into a specified blockchain. [(19:14)] For example, BCN 141 can generate blockchain transactions that include data1 and / or hash(data2). BCN 141 can send blockchain transactions to a designated blockchain network.

[0279] Step 15: After the blockchain transaction, including data1 and / or hash (data2), has been successfully added to the designated blockchain, BCN 141 may send a notification to BTC 142. In one embodiment, the transaction may have a transaction number TranNumX, and it may be included in a block with a sequence number equal to BlockNumY. The first request from BCA 143 may include a recipient (BCA, BTC, or BNA). The recipient may be connected to another BTM (“BTM-X”) (not shown). BTM-X may interact with another BCN (“BCN-X”) participating in the same blockchain system as BCN 141. Because the transaction propagates through the blockchain system, BCN-X should (can) receive the transaction. BCN-X may send the transaction to BTM-X. BTM-X may forward the transaction to the recipient.

[0280] Step 16: Optionally, BTC 142 may send a fifth request to update EDS 146 using the block sequence number BlockNumY and / or transaction sequence number TranNumX. [(16:16)] . EDS 146 can associate the block sequence number BlockNumY and transaction sequence number TranNumX with data2 previously stored in EDS 146. If data2 was not previously stored in EDS 146, step 16 should (may) be skipped.

[0281] Step 17: BTC 142 may forward the notification received from step 15 as an acknowledgment to BCA 143.

[0282] The program shown in Figure 19 can be used to support, but is not limited to, the following scenarios: Scenario 1: The requester can send data3 to BTC and request BTC to store data3 in a specified blockchain. BTC can store data3 in the specified blockchain via BCN. The requester can be BCA or another BTC. Scenario 2: The requester can send data4 and data5 to BTC. BTC can store data4 in the designated blockchain via BCN, and store data5 in EDS. The requester can be BCA or another BTC. Scenario 3: The requester can send the addresses of data6 and data7 to BTC. BTC can retrieve data7 from DPP (facilitated by BTM). BTC can store data6 in the designated blockchain and data7 in EDS. The requester can be BCA or another BTC. Scenario 4: The requester can send the addresses of data8 and data9 to BTC. BTC can retrieve data9 from DPP (facilitated by BTM). BTC can store data9 in the designated blockchain and data8 in EDS. The requester can be BCA or another BTC. • Scenario 5: The requester can send the addresses of data10 and data11 to BTC. BTC can retrieve data11 from DPP (facilitated by BTM). BTC can then store both data10 and data11 in a designated blockchain. The requester can be BCA or another BTC. • Scenario 6: The requester can send the address of data12 to BTC. BTC can retrieve data12 from DPP (facilitated by BTM). BTC can then store data12 in the designated blockchain. The requester can be BCA or another BTC. Scenario 7: The requester can send the addresses of data13 and data14 to BTC. BTC can retrieve data13 and data14 from DPP (facilitated by BTM). BTC can store data13 in the designated blockchain and data14 in EDS. The requester can be BCA or another BTC. • Scenario 8: The requester can send an event notification to BTC. BTC can use the event notification to locate blockchain policy rules (from locally stored blockchain policy rules or retrieved from DPP). BTC can retrieve any requested information and add it to the designated blockchain as described and specified in the blockchain policy rules. The requester can be BCA or another BTC.

[0283] Figure 20 illustrates a program 2000 for constructing BTC-controlled transactions for BTM subscription. For ease of explanation and simplicity, program 2000 is described with reference to transaction management architecture 1500 (Figure 15) and communication system 100 (Figures 1 and 5). Program 2000 can also be implemented using different architectures. Program 2000 may be suitable for scenarios where (i) BTC 142 can disclose one or more subscribing events that trigger BTC 142 to construct blockchain transactions, facilitate the construction of blockchain transactions, and / or facilitate the storage of information in EDS, and (ii) BTM 140 subscribes to one or more events disclosed by BTC.

[0284] Preprocessing: BCA 143 can log in to or be associated with BTC 142. BTC 142 can log in to or be associated with BTM 140; BTM has the address of BCN 141 and can communicate with it. BCN 141 is a participant in the designated blockchain system and maintains the designated blockchain (or decentralized ledger). Optionally, DPP 145 and EDS 146 may exist that are accessible to BTM 140. BCA 143 can be provided and / or configured to use the functionality provided by BTC 142. BTC 142 can be provided and / or configured to access the functionality of BTM 140. BTC 142 can be provided and / or configured to interact with the designated blockchain system via BCN 141. BTC 142 can be provided and / or configured to interact with the designated blockchain system on behalf of BCA 143. BCA 143 and BTC 142 can be co-located within the same device (e.g., smartphone, vehicle, drone, sensor) or hosted by two different devices. BTM 140, as a function, can reside (be configured) in devices, gateways, edge network components, 5G core network components, and / or data center components. BCN 141, as a function, can reside (be configured) in devices, gateways, edge network components, 5G core network components, and / or data center components.

[0285] Step 1: BTM 140 can send a subscription request to BTC 142 to subscribe to events revealed by BCA 143. [(20:1)] . A subscription request may include any of the following parameters: (i) an identifier of BCA 143. BCA 143 may trigger to add information to a specified blockchain when an event occurs; (ii) the conditions or event for subscription; (iii) the specified blockchain to which BCA 143 may add information; and (iv) an identifier of BTM.

[0286] Step 2: BTC 142 can send (forward) the subscription request to BCA [(20:2)] . BTC 142 can locally maintain one or more parameters from subscription requests.

[0287] Step 3: BCA 143 can handle subscription requests. BCA 143 can send an initial response (e.g., an immediate response) to BTC 142. [(20:3)] .

[0288] Step 4: BTC 142 can send (forward) the first response to BTM 140 [(20:4)] .

[0289] Step 5: The incident occurred at BCA 143 (detected by it). [(20:5)]. This event can trigger BCA 143 to send a request to BTC 142 to add information to the blockchain. [(20:5)], and / or perform other operations similar to those represented by step 1 of procedure 1900 (Figure 19).

[0290] Steps 8 to 22: Operations similar to those shown in steps 2 to 17 of procedure 1900 (Figure 19) can be performed to store the specified information in the specified blockchain and / or EDS.

[0291] Step 23: BCA 143 can send a notification to BTM 140 via BTC 142 to notify BTM 140 that the transaction has been added to the designated blockchain and that additional data has been stored in EDS 146. [(20:6)] . Alternatively, BTC 142 may send this notification to BTM 140. [Representative] [BTM] [Auxiliary Block Building]

[0292] Figure 21 illustrates a procedure 2100 for building a blockchain with BTM assistance. For ease of explanation and simplicity, procedure 2100 is described with reference to transaction management architecture 1400 (Figure 14) and communication system 100 (Figures 1 and 5). Procedure 2100 can also be implemented using different architectures. Procedure 2100 can be adapted for (i) BTM 140 to send assistance information to BCN 141, and (ii) each time a new block is built, the assistance information can be used by BCN 141 to select the appropriate scenario for pending transactions.

[0293] Preprocessing: The requester (BTC, BNA, or another BTM) can log in to or associate with BTM 140. BTM 140 has the address of BCN 141 and can communicate with it. BCN 141 is a participant in the designated blockchain system and maintains the designated blockchain (or decentralized ledger). DPP 145 and EDS 146 may exist that are accessible to BTM 140. The requester can access the functionality provided by BTM 140 by providing and / or configuring it. BTM 140 can interact with the designated blockchain system via BCN 141 by providing and / or configuring it. BTM 140 can interact with the designated blockchain system on behalf of the requester by providing and / or configuring it. BTC 140 may be located in a device (e.g., smartphone, vehicle, sensor). As a function, BTM 140 can reside (configured) in devices, gateways, edge network components, 5G core network components, and / or data center components. As a function, BCN 141 can reside (configured) in devices, gateways, edge network components, 3GPP core network components, and / or data center components.

[0294] Step 1: The requester can send a first request for one or more requirements on the block construction to BTM 140. [(21:1)]. The requester may be BNA 144, BTC 142, and / or another BTM (not shown). Such block building requests can cover a variety of scenarios, such as: (i) the transactions to be included in the new block should (may) come from a specific group of BCA, BTC, and / or BNA; (ii) the transactions to be included in the new block should (may) belong to a specific group of transaction categories; and (iii) the transactions to be included in the new block should (may) have an average latency of less than one value.

[0295] Step 2: BTM 140 can receive one or more first block build requests from the requester. [(21:2)] . BTM 140 can use DPP 144 to check whether the first request from the requester is allowed. During this step, DPP 144 can provide one or more new ("second") block building requests to BTM 140, which can overwrite or complement the first request.

[0296] Step 3: BTM 140 can send a first response confirming that the first block build request has been received to the requester. [(21:3)] 。 If BTM 140 retrieves a second block construction request from DPP 145, BTM 140 may include it in the first response to the requester.

[0297] Step 4: Based on the block construction requirements, BTM 140 can send a second request to BCN 141 to construct a set of transactions in a specific order. [(21:4)] To facilitate this, BTM 140 may access DPP 145 to retrieve one or more policies and / or additional information, and access EDS 146 to store additional information. In this procedure, BTM 140 may carry and send one or more block construction requests to BCN 141. This step may be optional. For this step, all parameters introduced in the transaction construction procedure controlled by BTM (e.g., transaction construction parameter set (step 3 of procedure 1600 in Figure 16) and additional transaction construction parameters (step 3' of procedure 1600 in Figure 16)) may be applied.

[0298] Step 5: Optionally, BTM 140 can search for existing but pending transactions from BCN 141 (or different BCNs) by providing transaction filters (e.g., the content of a filter) to BCN 141. As a result, BCN 141 can find all pending transactions against the transaction filters and can provide BTM 140 with a list of identifiers or sequence numbers of pending transactions that match the transaction filters. [(21:5)] 。 BTM 140 can maintain the list locally.

[0299] Step 6: BTM 140 can send block building requests to BCN 141 [(21:6)]. BCN 141 can send the second response to BTM. [(21:6)] Block building requirements may include the following scenarios and / or combinations thereof: (i) a subset of the list of pending transactions received from BCN 141 (step 5), which may trigger BCN 141 to build a new block to include all pending transactions included in such subset; and (ii) a first and / or second block building requirement.

[0300] Step 7: Based on the block construction requirements (Step 6), BCN 141 can select the corresponding pending transactions, construct a new block, and send the new block to the designated blockchain network. [(21:7)] .

[0301] Step 8: BCN 141 may send a third response to BTM 140, indicating the sequence number of the newly constructed block and a list of transactions included in the newly constructed block. [(21:8)] .

[0302] Step 9: BTM 140 can forward the response to the requester. [(21:9)] .

[0303] Not shown in Figure 21, after step 8 and when the new block has been fully confirmed in the designed blockchain system, BCN 141 may send a notification to BTM 140, which may then forward the notification to the requester. [Construction of representative transactions from multiple designated blockchains]

[0304] Figure 22 illustrates a program 2200 for constructing transactions controlled by a BTM. For ease of explanation and simplicity, program 2200 is described with reference to the transaction management architecture 1400 (Figure 14) and the communication system 100 (Figures 1 and 5). Program 2200 can also be implemented using different architectures. Program 2200 is suitable for scenarios where BNA 144 (or BCA / BTC 143 / 142 or BTM 140) can send (publish) requests to store information in multiple designated blockchains. Each designated blockchain can have a different BCN (e.g., BCNx for blockchain X, BCNy for blockchain Y, and BCNz for blockchain Z).

[0305] Procedure 2200 is suitable for scenarios where a BCN maintains and participates in multiple specified blockchains (or decentralized ledgers). For example, BCNx and BCNy can be the same BCN; otherwise, the separate requests in steps 8 and 10 can be combined into a single request. The rationale for using multiple blockchains instead of a single blockchain may be to further enhance security. Procedure 2200 in Figure 22 can cover, but is not limited to, the following two scenarios: • Scenario 1: BNA 144 can request to add information to blockchain X and other information to blockchain Y. In this scenario, steps 12 and 13 for interacting with BCNz can be skipped. Note that the scenario can be extended to more than two specified blockchains. • Scenario 2: BNA 144 can request that information be added to blockchain X and other information be added to blockchain Y (this can extend to more than two designated blockchains). Either BNA 144 or BTM 140 can decide to use another designated blockchain (e.g., blockchain Z and BCNz) ​​to maintain (recommend) the fact that information from BNA 144 has been added to blockchain X and blockchain Y. For this scenario, steps 12 and 13 are required for interacting with BCNz. • Scenario 3: BNA 144 can request to add information to multiple blockchain systems. BTM 140 can select blockchain X and blockchain Y (or more) to store information from BNA 144. In this scenario, BNA 144 does not need to specify a particular blockchain system; instead, it relies on BTM 140 to make the decision.

[0306] Preprocessing: BNA 144 (or BCA / BTC 143 / 142 or another BTM) can log in to or associate with BTM 140. BTM 140 has information related to multiple designated blockchains and corresponding BCN 141 (e.g., BCN address) and can communicate with the corresponding BCN 141. DPP 145 and EDS 146 may be accessible to BTM 140. BNA can be provided and / or configured to access the functionality provided by BTM 140. BTM 140 can be provided and / or configured to interact with multiple designated blockchains via BCN 141. As a function, BTM 140 can reside (configured) in devices, gateways, edge network components, 3GPP core network components, and / or data center components.

[0307] Step 1: BNA 144 can send the first request to add information and data to the designated blockchain to BTM 140. [(22:1)] And can perform an operation similar to step 3' of procedure 1600 (Figure 16) (where the first request corresponds to the second request in step 3' of procedure 1600). The first request may include two groups of transaction construction parameters ("transaction construction parameter groups"). Each group may include (i) a transaction construction parameter group, (ii) additional transaction construction parameters, and (iii) other transaction construction parameters.

[0308] Two transaction construction parameter groups are used to construct transactions into blockchains X and Y, respectively. BNA 141 can indicate whether BTM 140 needs to construct new transactions into blockchain Z to maintain the fact that information from BNA 144 has been added to blockchains X and Y (i.e., scenario 2). Alternatively, BNA 144 does not need to explicitly indicate blockchain X or blockchain Y, but indicates other parameters (such as the original data to be stored in the blockchain). Prior to step 1 (e.g., during system initialization, system setup, system provisioning and configuration, and / or during BNA 144 logging into BTM 140), BTM 140 may have already determined multiple blockchain systems and the corresponding BCN for BNA 144. Thus, BTM 140 may only need to receive other necessary information (such as the original data from BNA 141) and decide which data should (and can) be stored in which of the multiple blockchain systems used by BNA 141.

[0309] Step 2: BTM 140 can receive the first request. BTM 140 can then send a second request to DPP 145 to check any applicable blockchain policies and rules, as well as any additional information. [(22:2)] . In various embodiments, BTM 140 may have been configured with one or more blockchain policy rules via DPP 145, and may have automatically stored one or more blockchain policy rules. BTM 140 may use locally available blockchain policy rules before requesting and / or retrieving any blockchain policy rules from DPP 145.

[0310] For example, an identifier for a blockchain policy rule may be included in the first request. BTM 140 may submit this identifier to DPP 145 to retrieve the contents of the corresponding blockchain policy rule. The blockchain policy rule may specify: 1) the type, address, and / or identifier of the specified blockchain to be applied to one or more of the requests from BNA 144, BTC 142, and / or BCA 143; 2) whether there is any additional information to be added to the specified blockchain along with any specified information; and 3) where such additional information may be retrieved if not provided by DPP 145.

[0311] In another instance, the first request may include an address from which additional information can be retrieved. The BTM 140 can use this address to retrieve additional information from the DPP 145.

[0312] In another instance, the first request may not include any information content, but may include the address of the information to be added to the specified blockchain. The BTM 140 can use this address to retrieve the information from the DPP 145.

[0313] In another instance, BTM 140 can submit the identifier of BNA 144 to DPP 145 to retrieve any relevant blockchain policy rules and additional information.

[0314] Step 3: DPP 145 can send the first response to BTM 140 [(22:3)]. The first response may include the content of the blockchain policy rule, information to be added to the designated blockchain, and / or additional data to be added to the designated blockchain along with the information to be added. Additionally, whenever a blockchain policy rule is retrieved, BTM 140 may store it locally for future use, avoiding future retrievals of DPP 145 that may be instructed or commanded by DPP 145, or the costs associated with such future retrievals. DPP 145 may instruct BTM 140 that the blockchain policy rule returned may or should be stored locally.

[0315] Step 4: Based on the first response from DPP 145 and the first request from BNA 144, BTM 140 can determine the data to be added to the designated blockchain (referring to data X1 for blockchain X and data Y1 for blockchain Y) and the data to be stored in EDS 146 (referred to as data E). [(22:4)] . If there is no need to store any data in EDS 146, steps 6 and 7 can be skipped.

[0316] Step 5: BTM 140 allows you to select and specify the blockchain (Blockchain X and Blockchain Y) and the corresponding BCN (BCNx and BCNy). [(22:5)] 。 If the BTM 140 has been provided or configured with a specified blockchain and BCN, this step can be skipped or the BTM 140 can select the specified blockchain and the BCN for that specified blockchain again.

[0317] In one embodiment, the blockchain policy rule (e.g., retrieved from DPP 144 in step 4) may include specifying the blockchain and its corresponding BCN. Thus, this step may be omitted, or BTM 140 may again select either the specified blockchain and BCN. Alternatively, this step may also be omitted if the first instruction from BNA 144 specifies the blockchain and its corresponding BCN.

[0318] The BTM 140 may perform such BCN selection for the BNA 144 only once and may locally maintain information indicating the selected BCN. Indicating that the locally maintained by selected BCN for BNA 144 may be used when BTM 140 receives subsequent requests for construct transactions from BNA 144 . As another alternative, the BTM 140 may already select and assign one or more BCNs for BNA 144 on the basis of one or more indications and / or requirements from BNA 144 during the system setup and configuration phase. Thus, step 5 need not be implemented, and the first request from BNA 144 need not include or indicate BCN information.

[0319] Step 6: BTM 140 may send data E to EDS 146 and command EDS 146 to store data E [(22:6)] .

[0320] Step 7: EDS 146 stores dataE. EDS 146 may send a second response to BTM 143 [(22:7)] . The second response may include the address from which data E was retrieved.

[0321] Step 8: BTM may send data X1 (or its hash) to BCNx and ask it to store data X1 (or its hash) in blockchain X [(22:8)] .

[0322] Step 9: BCNx can generate a transaction including data X1 (transaction X1) and can send transaction X1 to the blockchain network X [(22:9)] . Finally, transaction X1 can be included in the new block #n (one instance is plotted in Figure 23 ). BCNx can send a third response to the BTM 140.

[0323] Step 10: BTM 140 may send data Y1 (or its hash) to BCNy and ask it to store data Y1 (or its hash) into blockchain Y [(22:10)] .

[0324] Step 11: BCNy can generate a transaction (transaction Y1) including data Y1 and send this transaction (transaction Y1) to blockchain network Y. Finally, transaction Y1 can be included in the new block #m (Figure 23 illustrates an example). BCNy can send the fourth response to BTM 140. [(22:11)] .

[0325] Step 12: When requested by BNA 144 in Step 1 or determined by BTM 140 based on relevant blockchain policies, BTM 140 may send a third request to BCNz to store the records of transaction X1 and transaction Y1 in blockchain Z. [(22:12)] The third request may include the following parameters: (i) the address of BCNx; (ii) the sequence number of block #n; (iii) the identifier and / or sequence number of transaction X1; (iv) the hash of transaction X1; (v) the hash of data X1; (vi) the address of BCNy; (vii) the sequence number of block #m; (viii) the identifier and / or sequence number of transaction Y1; (ix) the hash of transaction Y1; and / or (x) the hash of data Y1.

[0326] Step 13: BCNz can generate a transaction (transaction Z1) and send transaction Z1 to blockchain network Z. Transaction Z1 may include all or part of the list of parameters included in the third request (step 12). Finally, transaction Z1 can be included in the new block #p (Figure 23 illustrates an example). BCNz can send the fifth response to BTM 140. [(22:13)] .

[0327] Step 14: Optionally, BTM 140 may send a fourth request to update EDS 146 with information regarding where data X1 and data Y1 are stored. [(22:14)] 。 The fourth request may include information relating to block #p and transaction Z1 in blockchain Z, as illustrated in Figure 23.

[0328] Step 15: BTM 140 may send a sixth response to BNA 144, indicating whether the transaction requested in Step 1 has been successfully constructed and stored in the designated blockchain. [(22:15)] . The information that can be shown in Figure 23 is included in the sixth response. [Representative query transactions from the blockchain network]

[0329] Figure 24 illustrates a program 2400 for querying existing transactions (and / or blocks) from one or more specified blockchains. For ease of explanation and simplicity, program 2400 is described with reference to transaction management architectures 1400 and 1500 (Figures 14 and 15) and communication system 100 (Figures 1 and 5). Program 2400 can also be implemented using different architectures. Program 2400 is suitable for at least the following scenarios: • Transaction Inquiry Scenario 1: When the requester is a combination of BCA 143 and BTC 142, BCA 143 can send the transaction inquiry to BTC 142. BTC 142 can then forward the transaction inquiry to BTM 140. This interaction between BCA 143 and BTC 142 is not shown in Figure 24. • Transaction Inquiry Scenario 2: The requester can be BCA 143. BCA 143 can send the transaction inquiry to BTC 142. If BTC 142 previously constructed the transaction directly through multiple BCNs, it can directly access the BCNs without going through BTM 140. • Transaction Inquiry Scenario 3: The requester can be BNA 144, BTC 142, and / or BTM 140. The requester can send a transaction inquiry to another BTM. The other BTM can access multiple BCNs to inquire about transactions.

[0330] Preprocessing: The requester (BTC, BNA, and / or another BTM) can log in to or associate with BTM 140 (or the requester (BCA) can log in to or associate with BTC 142). BTM 140 (or BTC 142) has addresses of multiple BCNs (e.g., BCNx, BCNy, etc.) and can communicate with them via provision and / or configuration. An EDS 146 accessible by BTM 140 (or BTC 142) may exist. The requester can access the functionality provided by BTM 140 (or BTC 142) via provision and / or configuration. BTM 140 (or BTC 142) can interact with the designated blockchain system via BCN via provision and / or configuration. BTM 140 (or BTC 142) can interact with the designated blockchain system on behalf of the requester via provision and / or configuration. The requester may be located in a device (e.g., smartphone, vehicle, sensor). A BTM 140 (or BTC 142) as a function can reside (be configured) in devices, gateways, edge network components, 3GPP core network components, and / or data center components. Similarly, each of the BCNs as a function can reside (be configured) in devices, gateways, edge network components, 3GPP core network components, and / or data center components.

[0331] Step 1: The requester can send the first request to query existing blockchain transactions to BTM 140 (or BTC 142). [(24:1)]. The first request may include the following parameters: (i) a transaction filter (which provides criteria for finding any matching transaction); (ii) an identifier and / or address of the BCN; (iii) the category of the matching transaction; (iv) the time interval in which the matching transaction is constructed; (v) the identifier of one or more BTMs for which the BCN has been requested to construct the matching transaction; (vi) the identifier of one or more BTCs for which the BCN has been requested to construct the matching transaction; (vii) the identifier of one or more BCAs for which the BTM (or BTC) has been requested to construct the matching transaction; (viii) the identifier of one or more BNAs for which the BCN has been requested to construct the matching transaction; (ix) the transaction construction priority; and / or (x) the transaction inclusion priority.

[0332] Step 2: BTM 140 (or BTC 142) can process transaction query requests. [(24:2)]. BTM 140 (or BTC 142) can authenticate and authorize transaction query requests. BTM 140 (or BTC 142) can analyze transaction filters included in the request. By performing this analysis, BTM 140 can decide whether to contact (e.g., first contact) EDS 146. EDS 146 can maintain an association between locally stored data and the corresponding transactions stored in the specified blockchain. This association can simply be a pair of addresses of stored data and identifiers of the corresponding transactions. If the transaction filter is not related to the content of the transactions but to finding the total number of transactions constructed for a specific entity (e.g., BNA or BCA) within a time interval, BTM 140 (or BTC 142) can query such information directly from EDS 146 without contacting any BCN. During this step, BTM 140 can transform the transaction query into a new transaction query that can be easily understood by EDS 146 or BCN. The new transaction query may include transaction filters.

[0333] Step 3: If EDS 146 can respond to the transaction query as determined in Step 2, BTM 140 (or BTC 142) can send the new transaction query to EDS 146. [(24:3)] .

[0334] Step 4: The EDS can receive new transaction queries, find the association between locally stored data and the corresponding transaction stored in the blockchain, and infer one or more answers to the new transaction query. EDS 146 may include the answers in the first response and may send the first response to BTM 140 (or BTC 142). If EDS 146 finds one or more answers, steps 5 and 6 can be skipped.

[0335] Step 5: BTM 140 (or BTC 142) can select a list of BCNs to match against transaction filters and / or other criteria (e.g., if BCNs are currently available to support transaction queries). [(24:5)] . As an example, two BCNs (BCNx and BCNy) can be selected to participate in two different blockchain networks or the same blockchain network.

[0336] Step 6: BTM 140 (or BTC 142) can send the new transaction query generated in Step 2 to the selected BCN. [(24:6)] Each selected BCN can perform a transaction lookup using the matching transaction filter on its blockchain. Each BCN can respond with BTM 140 (or BTC 142) to send the query result (i.e., the answer to the matching transaction filter). [(24:6)] . BTM 140 (or BTC 142) can receive responses from each contacted BCN. [(24:6)] .

[0337] Step 7: BTM 140 (or BTC 142) can combine all received responses to produce the final query result. [(24:7)] .

[0338] Step 8: BTM 140 (or BTC 142) can send the final query results to the requester. [(24:8)] . [Subscription of representative transactions on the blockchain network]

[0339] Figure 25 illustrates a program 2500 for subscribing to events on a blockchain network. Events may include the creation of new transactions, the creation of new transactions for a specific entity, the creation of new transactions for a specific entity when it moves to a specific location, the creation of new blocks, etc. For ease of explanation and simplicity, program 2500 is described with reference to transaction management architectures 1400 and 1500 (Figures 14 and 15) and communication system 100 (Figures 1 and 5). Program 2500 can also be implemented using different architectures. Program 2500 is suitable for at least the following scenarios: • Transaction Subscription Scenario 1: The requester can be a combination of BCA 143 and BTC 142. BCA 143 can send the transaction subscription request to BTC 142. BTC 142 can send the transaction subscription request to BTM 140. This interaction between BCA 143 and BTC 142 is not shown in Figure 25. • Transaction subscription scenario 2: The requester can be BCA 143, and it can send the transaction subscription request to BTC 142. If BTC 142 previously constructed the transaction directly through one or more BCNs, it can directly access the BCN without going through BTM 140. • Transaction Subscription Scenario 3: The requester can be a BTM other than BNA 144, BTC 142, and / or BTM 140. The requester can send the transaction subscription request to BTM 140. BTM 140 can send the transaction subscription request to one or more BCNs.

[0340] Preprocessing: The requester (BTC 142, BNA 144, and / or another BTM) can log in to or associate with BTM 140 (or the request (BCA 143) can log in to or associate with BTC 142). BTM 140 (or BTC 142) has addresses of multiple BCNs and can communicate with them via provision and / or configuration. The requester can access the functionality provided by BTM 140 (or BTC 142) via provision and / or configuration. BTM 140 (or BTC 142) can interact with the designated blockchain system via multiple BCNs via provision and / or configuration. BTM 140 (or BTC 142) can interact with the designated blockchain system on behalf of the requester via provision and / or configuration. The requester may be located in a device (e.g., a smartphone, vehicle, sensor); a BTM (or BTC) as a function may be resident (configured) in a device, gateway, edge network element, 3GPP core network element, or data center element. A BCN as a function may be resident (configured) in a device, gateway, edge network element, 3GPP core network element, or data center element.

[0341] Step 1: The requester can send the transaction subscription request to BTM 140 (or BTC 142). [(25:1)]. A transaction subscription request may include the following parameters: subscription filter (which provides criteria for when and under what conditions BCN needs to generate notification messages).

[0342] Step 2: BTM 140 (or BTC 142) can handle transaction subscription requests. [(25:2)]. The BTM 140 (or BTC 142) can authenticate and authorize requests. The BTM 140 (or BTC 142) can analyze transaction filters included in the request. By performing this analysis, the BTM 140 (or BTC 142) can transform the transaction query from step 1 into a new transaction subscription request. The new transaction subscription request is more easily understood by the BCN. The new transaction subscription request may include a second subscription filter, which may include a standard subset or modified subscription filter of the subscription filters included in step 1.

[0343] Step 3: BTM 140 (or BTC 142) can select a list of BCNs to match with subscription filters and / or other criteria (e.g., if BCNs are currently available to support transaction queries, etc.). [(25:3)]. As an example, two BCNs (BCNx and BCNy) can be selected.

[0344] Step 4: BTM 140 (or BTC 142) can send the new transaction subscription request generated in Step 2 to the selected BCN. [(25:3)] Each selected BCN can process and store a second subscription filter. Each BCN can send a response message to BTM 140 (or BTC 142). The second subscription filter included in a new transaction subscription request to each selected BCN may be different and may be a subset of the original subscription filter.

[0345] Step 5: When a subscription event as described by the subscription filter occurs in BCN (e.g., BCNx) [(25:5)] , BCNx can generate notification messages. For example, a subscription event could be when a new transaction is constructed, as requested, by another BTM-Z for a blockchain-based V2X application. When BTM-Z (not shown in Figure 25) requests another BCNz to construct a new V2X transaction, and after the requested transaction is successfully constructed and sent to the blockchain network, BCNx (assuming BCNx and BCNz participate in the same blockchain network) can receive the transaction and can send a notification to BTM 140 (or BTC 142).

[0346] Step 6: BCNx can send a notification message to BTM 140 (or BTC 142). [(25:6)] .

[0347] Step 7: BTM 140 (or BTC 142) can forward the notification message to the requester. [(25:7)] . [Representative Analysis-Based Access Control in Blockchain Networks]

[0348] Figure 26 illustrates a program 2600 for analytics-based access control on a blockchain network. For ease of explanation and simplicity, program 2600 is described with reference to transaction management architecture 1400 (Figure 14) and communication system 100 (Figures 1 and 5). Program 2600 can also be implemented using different architectures. Program 2600 is suitable for scenarios where, when a requester (e.g., BTC 142 and / or BNA 144) requests to construct a transaction on a specified blockchain network, BTM 140 can use analytics results to perform some form of access control. Analytics results can be provided by a standalone analytics service or other BTMs.

[0349] Preprocessing: The requester (e.g., BTC 142 or BNA 144) can discover BTM 140-1. It may exist as a standalone service or provide analytics services as part of BTM 140-1 or other BTMs. BTM 140-1 may provide and / or be configured to have access to BCN 141-1. BTM 140-2 may provide and / or be configured to have access to BCN 141-2. BCN 141-1 and BCN 141-2 may be participants in the same blockchain network.

[0350] Step 1: The requester can log in to BTM 140-1 [(26:1)] . This can generate a new requester identifier (i.e., Req-ID) that is known to both BTM 140-1 and the requester.

[0351] Step 2: BTM 140-1 can send a first request to the analysis service to analyze blockchain transactions and generate analysis results based on specific analysis needs. [(26:2)], Such specific analysis requirements may be included in this first request. As part of the analysis requirements, the requester's identifier (i.e., Req-ID) may also be included in this request. As an example, the analysis requirement may be: "Calculate the average number of blockchain transactions constructed by the requester for the specified blockchain network in which BCN1 participates every 10 minutes." The identifier of BCN 141-1 (i.e., BCN1-ID) may be included as part of the analysis requirements. The analysis service may send a first response to BCN 141-1 to indicate whether it accepts or rejects the analysis requirements indicated from BTM 141-1. [(26:2)] .

[0352] Step 3: Based on all accepted analysis requests, the analysis service can determine what types of information can be collected from BCN 141-1 and at what frequency. The analysis service can send subscription requests to BCN 141-1 for data collection purposes and can expect to receive automatic notifications from BCN 141-1. [(26:3)] . Subscription requests may include subscription filters, which may be derived from accepted analytics requests. BCN 141-1 can process subscription requests, store subscription filters, and send a second response to the analytics service.

[0353] Step 4: The requester can use BTM 140-1 to communicate with BCN 140-1 to construct new transactions on the blockchain network in which BCN 140-1 participates. BCN 140-1 can generate new transactions and send them to the blockchain network. [(26:4)] .

[0354] Step 5: Transactions generated in Step 4 must conform to the subscription filters received by BCN 141-1 in Step 3. BCN 141-1 may then send the first notification to the analytics service. [(26:5)] Based on the subscription filter, BCN 141-1 can generate notifications for the requester at time T1 using the transaction analysis service. BCN 141-1 may include some other post-processing information related to the generated transaction in the first notification.

[0355] Step 6: Based on the notification from BCN 141-1, the analysis service can perform calculations and certain analysis algorithms to produce analysis results. [(26:6)] . The analysis service can receive multiple notifications from BCN 141-1 and perform a single analysis on it. The analysis service can maintain the analysis results, which can be retrieved / subscribed to by other entities (such as BCN 141-1 and BCN 141-2). Alternatively and / or additionally, the analysis service can proactively push selected analysis results to specific entities.

[0356] Step 7: The requester may send a second request to construct another transaction to BTM 140-1 [(26:7)] .

[0357] Step 8: BTM 140-1 can send a third request to the analytics service to examine the analysis results relevant to the requester. [(26:8)]. The third request may include parameters such as the requester's Req-ID, the identifier of BTM 140-1 (BTM1-ID), and / or BCN1-ID. The analysis service may (i) receive the third request, (ii) use the parameters included in the third request to find appropriate analysis results, and (iii) return any found analysis results to BTM 140-1. [(26:8)] .

[0358] Step 9: BTM 140-1 can use the analysis results received from the analysis service to perform access control on the second request. [(26:9)] For example, if the analysis results show that the average transaction generation rate in the past 10 minutes exceeds the threshold, BTM 140-1 can reject the second request, and step 10 can be skipped.

[0359] Step 10: If access control permits a third request, BTM 140-1, together with BCN 141-1 and the requester, may perform the other requested steps to construct a new transaction for the requester as requested in step 7. [(26:10)] .

[0360] Step 11: If a new transaction has been constructed as a result of Step 10, similar to Step 5, BCN 141-1 can send a second notification to the analytics service. [(26:11)] .

[0361] Step 12: Similar to step 6, the analysis service may perform analysis as needed on the second notification together with previously received notifications and / or any previously generated analysis results. [(26:12)] .

[0362] Step 13: The requester may choose another BTM 140-2 [(26:13)] .

[0363] Step 14: Similar to Step 1, the requester logs into BTM 140-2. [(26:14)] 。 Along with other parameters included in step 1, the requester may include additional parameters such as the BTM1-ID and Req-ID assigned by BTM 140-1.

[0364] Step 15: Similar to step 7, the requester can send a fourth request to construct a new transaction to BTM 140-2. [(26:15)] 。 The fourth request may include the identifier of BCN 141-2 (i.e., BCN2-ID).

[0365] Step 16: Similar to step 8, BTM 140-2 can directly check the analysis results from the analysis service. [(26:16)] . Alternatively, the BTM 140-2 can use its accessible analysis service and transmit the analysis results back to the BTM 140-1 inspection unit of the BTM 140-2. [(16:16)] .

[0366] Step 17: Similar to step 9, BTM 140-2 can perform the access control request for the fourth request based on the analysis results received from step 16. [(26:17)] .

[0367] Step 18: If access control passes, BTM 140-2 can forward the fourth request to BCN 141-2. [(26:18)] . BCN 141-2 can generate a new transaction as requested and send a second response to BTM 140-2.

[0368] Step 19: BTM 140-2 can forward the second response to the requester. [(26:19)] .

[0369] Step 20: After a new transaction is generated by BCN 141-2 and entered into the blockchain network, due to the broadcast nature of the P2P network used by the blockchain network, BCN 141-1 may be able to monitor and detect this. [(26:20)] .

[0370] Step 21: Similar to steps 5 and 11, since the analytics service is subscribed to by BCN 141-1, BCN1 can send a third notification to the analytics service. [(26:21)] .

[0371] Step 22: Similar to steps 6 and 12, the analysis service may perform analysis on a third notification and / or, as needed, on any previously received notification. [(26:22)] . [5GS] [Representative architecture implementation]

[0372] Figure 27 shows an embodiment of the blockchain transaction management-related logical entities in the context of 5G and beyond the communication system architecture. For ease of explanation and simplicity, the communication system architecture and the blockchain transaction management-related logical entities are described with reference to the functional architecture 1400 and the architecture description of the communication system 100. The core network refers to either the 5G core network or a future wireless core network.

[0373] The BTM 140 can be implemented as a new control plane NF or AF. The BTM 140 can reside (configured) in the core network and / or edge network. The BTM 140 may need to interact with one or more existing core network functions. For example, the BTM 140 can register itself with the NRF, enabling it to discover other NFs and / or be discovered by them. The BTM 140 can use AUSF and / or PCF to authenticate any blockchain transaction management-related requests received from WTRU 1, 2. The BTM 140 can use PCF to examine any blockchain transaction management-related policies and rules. The BTM 140 can use UDSF to store blockchain-related policies. The BTM 140 can use USDF to store additional data and / or links to transaction and / or blockchain blocks. The BTM 140 can be disclosed to or accessed by third parties via NEF. The BTM 140 can use NWDAF to analyze other characteristics of transactions and / or the blockchain.

[0374] BTM 140 can be implemented as part of existing network functionality (such as NEF). BCN 141 can be a new NF provided by a third party, either within the core network or outside the core network. If BCN 141 is provided by a third party, BTM 140 can access it via NEF. BNA 144 can be implemented as an AF. If BNA 144 is provided by a third party, it can interact with BTM 140 via NEF, but direct interaction with BTM 140 is prevented. BCA 143 and BTC 142 can be implemented within a WTRU. Alternatively, a WTRU with constrained resources (such as a narrowband IoT device) can host only BCA 143, and BTC 142 can be hosted by other robust WTRUs (such as vehicles, gates, edge servers, etc.). DPP 145 can be implemented as a combination of PCF and UDSF. EDS 146 can be implemented as a UDSF. Analytics services can be implemented as part of NWDAF.

[0375] As shown in Figure 28, the BNA 144 can be implemented as a new functionality to become part of any current 5G network function NF3 (e.g., AMF), enabling this NF3 to interact with the BTM 140 and send transactions to the blockchain network. For example, when the SMF receives a PDU establishment request, the SMF with embedded BNA 144 can send this event to the blockchain network in a transaction via the BTM 140. In another instance, when the NRF receives an NF login request, the NRF with embedded BNA 144 can send this event to the blockchain network in a transaction via the BTM 140. The interaction between the BNA 144 and the BTM 140 can be implemented as a new procedure between the current NF and the BTM 140.

[0376] As shown in Figure 28, BTC 142 can be implemented as part of any current 5GC network function NF1 (such as Service AMF). Thus, WTRU1 (or WTRU2) can host BCA 143a (or BCA 143b) but not BTC. BCA 143a (or BCA 143b) hosted by WTRU1 (or WTRU2) can communicate with BTC 142 hosted by network function NF1. The interaction between BCA 143a, 143b and BTC 142 can be implemented as a new procedure between WTRU and individual network functions NF1 (e.g., Service AMF).

[0377] As shown in Figure 28, the BTM 140 can be implemented as part of a current 5G network function NF2 (such as UDSF). Other network functions can interact with NF2 to use the services provided by the embedded BTM 140 disclosed herein. For example, if the UDSF has an embedded BTM 140, other NFs can request the UDSF to construct transactions to the blockchain network. As a result, the UDSF can interface with the BCN to perform BTM-to-BCN and BCN-to-BTM interactions.

[0378] UDSF (and / or UDR) can use BTM 140 to store data in the blockchain network to achieve decentralized data storage within 5GC. For example, UDSF may include an embedded BNA 144. Whenever UDSF receives a data storage request, it can use the embedded BNA 144 to communicate with BTM 140 and thereby store the data in the blockchain as a transaction. Alternatively, UDSF may host BTM 140. UDSF may also interact directly with BCN 141 to store data in the blockchain network.

[0379] The NRF can use the BTM 140 to store NF login records to the blockchain network, enabling a decentralized NF login repository within 5GC. For example, the NRF can include an embedded BNA 144. Whenever the NRF receives an NF login request, it can communicate with the BTM 140 using the embedded BNA 144 and store the new NF login record to the blockchain in a transactional manner. Alternatively, the NRF can host the BTM; and the NRF can interact directly with the BCN 141 to store data to the blockchain network. [5GS] [Representative Chinese Receiver] [BTM] [Controlled Transaction Construction]

[0380] Figure 29 illustrates a procedure 2900 for constructing transactions controlled by a BTM. For ease of explanation and simplicity, procedure 2900 is described with reference to the communication system architecture of Figure 27 and / or Figure 28. Procedure 2900 can also be implemented using different architectures. Procedure 2900 is suitable for scenarios where a requester can trigger a BTM to construct a new transaction to a specified blockchain network. The entities involved in this procedure include the requester, BTM, PCF, NF, UDSF, BCN, and the notification target.

[0381] In various embodiments, the requester may be (i) a WTRU having a BCA and / or BTC, (ii) an NF (e.g., AMF), or (iii) an AF, such as a BNA. The BTM can be implemented as a control plane NF or AF. The notification target can be NF, AF, or BNA. When the requester is a WTRU, the WTRU may communicate with the BTM via its service AMF. When the requester is a BNA, the requester may communicate with the BTM via the NEF. When the requester is NF and BTM is NF, the requester can communicate with BTM via NEF. When BTM is AF, the requester can communicate with other core network functions (i.e., PCF, NF, and UDSF) via NEF.

[0382] Preprocessing: The requester may log in to or associate with the BTM and may be provided or configured to use its functionality. The BTM may have been associated with the BCN of the blockchain network and may be provided and / or configured to request it to construct the transaction into the specified blockchain. The BTM has the address of the NRF and can be provided and / or configured to discover other NFs from the NRF.

[0383] Step 1: The requester can send the trigger request to the BTM to construct the transaction on the specified blockchain [(29:1)] . The trigger request may include (i) a set of transaction build parameters, (ii) additional transaction build parameters, (iii) all or some of other transaction builds, and may include an identifier for the notification target.

[0384] When the requester is a WTRU, the trigger request may include the following additional parameters: (i) the identifier of the WTRU (i.e., WTRU-ID); When the requester is an NF, the trigger request may include the following additional parameters: The identifier of the NF (i.e., NF-ID).

[0385] Step 2: BTM may send the first request to the PCF to check any applicationable blockchain policy rules against the requester [(29:2)] . The first request may include an identifier of the requester. After receiving the first request, if the requester is a WTRU, the PCF can retrieve the subscription data of the requester from the UDR. PCF can generate one or more new blockchain policy rules. The PCF can send the first response to the BTM [(29:2)] . The first response may include one or more blockchain policy rules that can be applied to the BTM and / or the requester.

[0386] Step 3: The BTM can receive trigger requests from the requester. The BTM may need to authenticate the trigger request. [(29:3)] For this purpose, the BTM may contact the AUSF to retrieve the requester's authentication credentials. The BTM may use the authentication credentials and policy rules (which may be maintained locally and / or received from the PCF in step 2) to trigger the authentication request. If authentication is successful, the following steps may be performed; otherwise, the following steps may be skipped.

[0387] Step 4: If the triggering request indicates that the BTM may need to retrieve additional data from one or more NFs, the BTM may contact one or more corresponding NFs to retrieve the additional data. [(29:4)] For example, when the requester is a WTRU, the WTRU may indicate in the triggering request that the BTM may need to retrieve its location from its serving AMF as additional information by indicating the address or identifier of its serving AMF.

[0388] Step 5: Similar to step 6 of procedure 1600 in Figure 16, BTM can determine the data to be stored in the designated blockchain (referred to as Data-for-BC) and the data to be stored in UDSF (referred to as Data-for-Non-BC). [(29:5)] , Given all data related to the operations received in steps 1 and 4.

[0389] Step 6: Similar to step 7 of procedure 1600 in Figure 16, if no requester's BCN was specified in step 1, the BTM may select the requester's BCN. [(29:6)] . Assuming BCN registers itself with the NRF, BTM can search for BCN from that NRF. If BCN registers itself with BTM, BTM can search for BCN from its local database that maintains (e.g., all) the databases that have BCN registered.

[0390] Step 7: BTM can send data storage requests to UDSF. [(29:7)]. A data storage request may include a Data-for-Non-BC and one or more additional parameters, such as the requester's identifier and the BTM's identifier. The UDSF may store a Data-for-Non-BC with post-processing information, including, but not limited to, the build time, the requester's identifier, the BTM's identifier, and the address of the stored Data-for-Non-BC. This step may be similar to steps 8 and 9 of procedure 1600 in Figure 16.

[0391] Step 8: BTM can access BCN to store Data-for-BC and Hash (Data-for-Non-BC) to the designated blockchain. [(29:8)] . As a result, transactions can be generated via BCN and stored in a distributed ledger. Operations similar to those in steps 10, 11, 14, and 15 of procedure 1600 shown in Figure 16 can also be performed.

[0392] Step 9: BTM can send the transaction information (as generated in Step 8) along with a request for Data-for-Non-BC and additional meta-data to UDSF. [(29:9)]. Data-for-Non-BC is stored in UDSF because it represents the operation in step 7. The operation is similar to the operation represented in step 16 of procedure 1600 in Figure 16.

[0393] Step 10: BTM can send the first notification to the requester. [(29:10)] The first notification may include the address of the Data-for-Non-BC stored in the UDSF and information related to the transaction generated in step 8.

[0394] Step 11: BTM can send the second notification to the notification target. [(29:11)] . The address of the notification target may have been included in the trigger request from the requester (step 1), in the first request to the PCF (step 2), and / or determined locally by the BTM. [5GS] [Representativeness in the marginalized] [BTM] [Controlled Transaction Construction]

[0395] 30 illustrates a procedure 3000 for transaction construction under BTM control. For the convenience and simplicity of the illustration, procedure 3000 is described with reference to the communication system architecture of FIG. Procedure 3000 can also be implemented using different architectures. Procedure 3000 may be adapted (for) scenarios where edge BTM coordination to construct transactions to a specified blockchain for the requester. Entities involved in procedure 3000 include a requester, an edge BTM, an edge BCN, a core BTM disposed in a component of the CN / hosted by that component of the CN, a PCF, NF, UDSF, a component disposed in / a core BCN hosted by the component of the core network, and a notification target.

[0396] In various embodiments, the requester may be a WTRU having BCA and / or BTC. The edge BTM and edge BCN are provided in / are hosted by the one or more components of the edge network approaching the requester. Edge BTM and core BTM can be implemented as control plane NF or AF. The notification target can be BNA, NF, or AF. When the requester is a WTRU, the WTRU may use the edge network to communicate directly with the edge BTM and through its service AMF with the core BTM. When BTM is AF, it can communicate with other core network functions (i.e., PCF, NF, and UDSF) via NEF. Edge BTM and core BTM can communicate with each other directly or via NEF.

[0397] Preprocessing: The requester may log in to or associate with that edge BTM and may use its functionality. The edge BTM may be logged into or associated with a core BTM and may be provided or configured to use its functionality. The edge BTM may be associated with the edge BCN of the specified blockchain network and may be provided and / or configured to request it to construct the transaction to the specified blockchain network. The core BTM has the address of the NRF and can communicate with it by provision and / or by configuration. The core BTM can be provided and / or configured to discover other NFs from the NRF.

[0398] Step 1: The requester can send the trigger request for the requesting edge BTM to construct the transaction to the specified blockchain network to the edge BTM [(30:1)]. The trigger request may include all or some of the parameters included in step 3 or step 3' of Figure 16, and may include an identifier of the notification target. When the requester is a WTRU, the trigger request may include the following additional parameters: (i) the identifier of the WTRU; (ii) the address of the WTRU; and (iii) other background information related to the WTRU, such as connectivity, battery level, etc. When the requester is an NF, the trigger request may include the following additional parameter: the identifier of the NF.

[0399] Prior to step 1, the requester may have already assigned an identifier to the edge BTM via the core BTM, enabling the requester to communicate with the edge BTM. As part of the new blockchain configuration policy rules for the requester and based on the background information of both the requester (e.g., its current location) and the background information of the edge BTM (e.g., its service area and current traffic load), the core BTM may have assigned the edge BTM to the requester.

[0400] Step 2: The edge BTM can send the first request for retrieving new blockchain policy rules to the core BTM. [(30:2)] . The core BTM can process the first request as follows:

[0401] Scenario 1: If the core BTM has maintained one or more local blockchain policy rules that can be applied to the edge BTM and the requester, the core BTM can directly send the first response, including the content of such policy rules, to the edge BTM without contacting the PCF. The core BTM can include information configuring the edge BTM using the identifiers of the new edge BCN and NF in the first response message.

[0402] Scenario 2: Otherwise, the core BTM can forward the first request to the PCF and may notify the PCF of one or more parameters (such as, for example, the requester's identifier, the edge BTM's identifier, the core BTM's identifier, etc.). The PCF can process the first request and may contact the UDR to obtain the requester's subscription information based on the new blockchain policy rules generated by the PCF. The PCF may send a second response, including the content of the new blockchain policy rules, to the core BTM. The core BTM may send the second response to the edge BTM. The core BTM may include information configuring the edge BTM using the identifiers of the new edge BCN and NF in the second response message. The operation performed by the PCF in Scenario 2 can be similar to the operation performed by the PCF in step 2 of Figure 29.

[0403] The core BTM can include information indicating and / or commanding the edge BTM that can directly or indirectly contact the NF in the first / second response message.

[0404] Step 3: The BTM can receive trigger requests from the requester. The BTM may need to authenticate the trigger request. [(30:3)] For this purpose, the BTM may contact the AUSF to retrieve the requester's authentication credentials. The BTM may use the authentication credentials and policy rules (which may be maintained locally and / or received from the PCF) to trigger the authentication request. If authentication is successful, the following steps may be performed; otherwise, the following steps may be skipped.

[0405] Step 4: Similar to step 4 in Figure 29. If the triggering request indicates that additional data is needed for the NF, the edge BTM can communicate with the NF to retrieve the additional data. [(30:4)] [。] The edge BTM can communicate directly or indirectly with the NF (e.g., communication between the edge BTM and the NF can be relayed via the core BTM). In various embodiments, the edge BTM can receive a first / second response message sent to the edge BTM (step 2). The first / second response may include information indicating and / or commanding the edge BTM that it can directly or indirectly contact the NF. The edge BTM can determine whether to communicate directly or indirectly with the NF based on this information.

[0406] Step 5: Similar to step 5 in Figure 29. The edge BTM can determine whether Data-for-BC to be stored in the specified blockchain or Data-for-Non-BC to be stored in UDSF. [(30:5)] , Given all data related to the operations received in steps 1 and 4.

[0407] Step 6: Similar to step 6 in Figure 29. The edge BTM can be selected for the edge BCN of the requester. [(30:6)]. Assuming the BCN registers itself with the NRF, the BTM can search for the edge BCN from the NRF. In various embodiments, the first / second response message (step 2) from the core BTM may include an identifier of the edge BCN. The edge BTM can select the edge BCN based on the identifier of the edge BCN.

[0408] Step 7: Similar to step 7 in Figure 29. The edge BTM can send data storage requests to UDSF. [(30:7)]. The edge BTM can send data storage requests to the UDSF directly or indirectly via the core BTM. In various embodiments, the first / second response message (step 2) from the core BTM may include information instructing and / or commanding the edge BTM to communicate directly or indirectly with the UDSF and / or indicating the address of the UDSF. The edge BTM can determine whether to communicate directly or indirectly with the UDSF based on this information.

[0409] Step 8: Similar to step 8 in Figure 29. The edge BTM can contact the BCN to store Data-for-BC and Hash (Data-for-Non-BC) to the designated blockchain. [(30:8)]. Operations similar to those shown in steps 10, 11, 14, and 15 of procedure 1600 in Figure 16 can also be performed. Step 9: Similar to step 9 in Figure 29. The edge BTM can send a second request to UDSF, attaching the transaction-generating information to Data-for-Non-BC and additional post-processing data. [(30:9)]. Data-for-Non-BC may be stored in the UDSF as indicated by the operation in step 7. The edge BTM may send the second request to the UDSF directly or indirectly via the core BTM. In various embodiments, the first / second response message from the core BTM (step 2) may include information instructing and / or commanding the edge BTM to send the request directly or indirectly via the core BTM or otherwise communicate with the UDSF, and / or indicating the address of the UDSF. The edge BTM may determine whether to communicate directly or indirectly with the UDSF based on this information. The operation is similar to the operation shown in step 16 of procedure 1600 in FIG. 16.

[0410] Step 10: Similar to step 10 in Figure 29. The edge BTM can send the first notification to the requester. [(30:10)] The first notification may include the address of the Data-for-Non-BC stored in the UDSF and information related to the transaction generated in step 8.

[0411] Step 11: The edge BTM can generate a third notification (Step 8) that may include background information related to the transaction. The background information may include post-processing data and post-processing data stored in the UDSF. The edge BTM can send the third notification to the core BTM. [(30:11)] 。 If steps 7 and 9 have already been executed by the core BTM, this step can be skipped.

[0412] Step 12: The transaction constructed in step 8 can be successfully confirmed in the specified blockchain as detected by the core BCN [(30:12)] .

[0413] Step 13: The core BCN can send a second notification to the core BTM [(30:13)] . The second notice may include background information including its contents and sequential information for the transaction confirmed in step 12 . The core BTM can be subscribed by the core BCN to receive this notification.

[0414] Step 14: The core BTM may send a third notification to the notification target to notify it of the transaction (Step 13) [(30:14)] . This step may be similar to step 11 in Figure 29 . Alternatively, the edge BTM may send this one notification to the notification target after step 10 . The core BTM can send this notification to the edge BTM. [5GS] [Representatives in] [AF] [Transaction Build for Subscription]

[0415] 31 illustrates the procedure 3100 for transaction construction for AF subscriptions. For convenience and simplicity of illustration, procedure 3100 is described with reference to the communication system architecture of FIG. Procedure 3100 may also be implemented using different architectures. The procedure 3100 may be adapted (for) an AF or BTM to subscribe to NF1 (e.g., AMF, SMF, UPF) such that when a subscription event occurs at NF1, NF1 may trigger the BTM to construct a scenario of the transaction. The entities involved in this procedure include AF, BTM, NF1, PCF, NF2, UDSF, BCN, and Notified Target. AF can communicate with BTM via NEF. The BTM can be implemented as a control plane NF or AF. When BTM is AF, it can communicate with other core network functions (i.e., PCF, NF2, and UDSF) via NEF.

[0416] Preprocessing: AF may be logged into or associated with a BTM and may be provided or configured to use its services. The BTM has the address of the NRF and can communicate with it;BTM may be provided and / or configured to discover other NFs from the NRF. The BTM may be associated with the BCN of the specified blockchain network and may be provided and / or configured to request it to construct the transaction to the specified blockchain.

[0417] Step 0: Either AF or BTM can send a subscription request to NF1. [(31:0)] . The subscription request may include an identifier for the BTM and / or an identifier for the AF. It may include subscription filters indicating one or more conditions or expected events that, if they occur later in NF1, may trigger NF1 to send a notification to NF1. NF1 may receive this subscription request and may store the subscription filters.

[0418] Step 1: NF1 can monitor its status and any events that occur, and can compare each event with the stored subscription filters. [(31:1)] When a match is found, NF1 may send a notification to BTM. This notification may include the following parameters: (i) the identifier of NF1; (ii) the content of the match event (for example, if the match event is a WTRU logging in with its serving AMF, the content of this event may include the identifier of the WTRU, the location of the WTRU, the event time, the identifier of the serving AMF, etc.).

[0419] Steps 2 to 10: Operations similar to those represented by steps 2 to 10 of procedure 2900 (Figure 29) can be performed.

[0420] Step 11: BTM can send the second notification to the notification target. [(31:11)]. The address of the notification target may have been included in the trigger request (step 1), in the first request to the PCF (step 2), and / or determined locally by the BTM. The BTM may send the same notification to NF1. [pass] [5GS] [Control plane] [WTRU] [Triggered Blockchain Transaction Construction]

[0421] 32 illustrates the procedure 3200 for the construction of a blockchain transaction triggered by WTRU. For convenience and simplicity of illustration, procedure 3200 is described with reference to the communication system architecture of FIG. Procedure 3200 can also be implemented using different architectures. Procedure 3200 may be adapted (for) a scenario in which a WTRU triggers a BTM to construct a transaction through a 5GS control plane to a specified blockchain network (in which BCN participates). The entities involved in this procedure include WTRU, Service AMF, BTM, PCF, LMF (or other NF), UDSF, BCN, and Notification Target. In this case, the WTRU may have BCA / BTC. The BTM can be implemented as a control plane NF or AF. The notification target can be AF, NF, BNA, or event another WTRU. The WTRU may communicate with the BTM via its service AMF. When the BTM is AF, it can communicate with other core network functions (i.e., service AMF, PCF, LMF, and UDSF) via NEF.

[0422] Preprocessing: The WTRU can be connected to its service AMF (i.e., in the CM-CONNECTED state). A WTRU (e.g., a BCA / BTC thereof) may be logged into or associated with a BTM and may be provided or configured to use its functionality. The BTM may be associated with the BCN of the specified blockchain network and may be provided and / or configured to request it to construct the transaction to the specified blockchain. The BTM has the address of the NRF and communicates with it;BTM may be provided and / or configured to discover other NFs from the NRF.

[0423] Step 1: Similar to Step 1 in Figure 29 . The WTRU may send a trigger to its service AMF in a request, which may forward the trigger request to the BTM [(32:1)] . If the identifier of the BTM is not included in the trigger request from the WTRU, the service AMF may search the BTM from the NRF and / or UDSF to find the BTM with which the WTRU can communicate. The service AMF can forward the trigger request to the BTM. If no BTM is available, the service AMF can buffer the received request from the WTRU. The service AMF has access to the AUSF to retrieve the authentication token of the WTRU and the UDM to retrieve the subscription data of the WTRU. Based on the authentication token and subscription data, the service AMF can throw down the trigger request without forwarding it to the BTM.

[0424] Step 2: BTM may send the first request to the PCF to check any applicationable blockchain policy rules against the requester [(32:2)]. The first request may include the requester's identifier. Upon receiving the first request, if the requester is a WTRU, the PCF can retrieve the requester's subscription information from the UDR. The PCF may generate one or more new blockchain policy rules. The PCF may send the first response to the BTM. [(32:2)]. The first response may include one or more blockchain policy rules that can be applied to BTM and / or the requester.

[0425] Step 3: The BTM can receive trigger requests from the requester. The BTM may need to authenticate the trigger request. [(32:3)] For this purpose, the BTM may contact the AUSF to retrieve the requester's authentication credentials. The BTM may use the authentication credentials and policy rules (which may be maintained locally and / or received from the PCF in step 2) to trigger the authentication request. If authentication is successful, the following steps may be performed; otherwise, the following steps may be skipped.

[0426] Step 4: If the triggering request indicates that the BTM can retrieve additional information, such as the current location of the WTRU as an example, the BTM can send the location request directly to the LMF or to the service AMF that can retrieve the location on behalf of the BTM. Finally, the BTM will obtain the current location of the WTRU directly from the LMF or from the service AMF.

[0427] Steps 5 to 9: Operations similar to steps 5 to 9 of procedure 2900, using the WTRU identifier (i.e., WTRU-ID) (Figure 29), can be performed.

[0428] Step 10: Similar to step 10 in Figure 29. The BTM can send a notification to the WTRU, which can be relayed via the WTRU's serving AMF. If the serving AMF has changed, the BTM can search for it from the UDM (or from the NRF) by providing the WTRU-ID.

[0429] Step 11: A similar operation to step 11 of procedure 2900 (Figure 29) can be performed.

[0430] 33 illustrates the procedure 3200 for the construction of a blockchain transaction triggered by WTRU. For the convenience and simplicity of the illustration, procedure 3300 is described with reference to the communication system architecture of FIG. Procedure 3300 can also be implemented using different architectures. Procedure 3300 may be adapted (for) a scenario in which a second WTRU2 may assist the first WTRU1 to construct a transaction to a specified blockchain through the 5GS control plane in which the BCN participates. In this case, WTRU1 may be a constrained device and may escrow BCA only, whereas WTRU2 may be more powerful and escrow BTC to serve the BCA in WTRU1.

[0431] The entities involved in this procedure include WTRU1, WTRU2, Service AMF, BTM, PCF, LMF (or other NF), UDSF, BCN, and Notification Target. The BTM can be implemented as a control plane NF or AF. The notification target can be AF, NF, BNA, or even another WTRU. WTRU2 can communicate with BTM via its service AMF. When the BTM is AF, it can communicate with other core network functions (i.e., service AMF, PCF, LMF, and UDSF) via NEF.

[0432] Preprocessing: WTRU1 has discovered WTRU2 and can be provided and / or configured to communicate with WTRU2 directly or indirectly via 5GS. WTRU2 may be connected to its service AMF (i.e., in the CM-CONNECTED state). A BCA on WTRU1 may be logged into or associated with a BTC on WTRU2. WTRU2 (e.g., BTC thereof) may be logged into or associated with a BTM and may be provided or configured to use its functionality. The BTM may be associated with the BCN of the specified blockchain and may be provided and / or configured to request it to construct the transaction to the specified blockchain network. The BTM has the address of the NRF and can communicate with it by provision and / or by configuration. The BTM may be provided and / or configured to discover other NFs from the NRF.

[0433] Step 0: WTRU1 can send the trigger request to WTRU2 [(33:0)] . This trigger request may include the same parameter group as included in step 1 of FIG.

[0434] Step 1: Similar to Step 1 in Figure 32 , but the trigger sent from WTRU2 to BTM may include identifiers of WTRU1 and WTRU2.

[0435] Step 2: Similar to step 2 in Figure 32. BTM can provide the identifiers of WTRU1 and WTRU2 to PCF and request blockchain policy rules that can be applied to WTRU1 and / or WTRU2.

[0436] Step 3: Similar to step 3 in Figure 32. The BTM can authenticate the received trigger requests for both the identifiers of WTRU1 and WTRU2.

[0437] Step 4: Similar to step 4 in Figure 32. The BTM may request retrieval of the current location and / or other information regarding WTRU1 and / or WTRU2.

[0438] Step 5: Similar to step 5 in Figure 32.

[0439] Step 6: Similar to step 6 in Figure 32.

[0440] Step 7: Similar to step 7 in Figure 32. The BTM may notify the UDSF of the identifiers of WTRU1 and WTRU2, which may store these identifiers as part of the metadata of the data to be stored as requested by the BTM.

[0441] Step 8: Similar to step 8 in Figure 32. The constructed transaction may include the identifier of WTRU1 and / or the identifier of WTRU2.

[0442] Step 9: Similar to step 9 in Figure 32.

[0443] Step 10: Similar to step 10 in Figure 32.

[0444] Step 11: Similar to step 11 in Figure 32.

[0445] Step 12: WTRU2 may forward the notification received from step 10 to WTRU1.

[0446] 34 illustrates the procedure 3400 for the construction of a blockchain transaction triggered by WTRU. For the convenience and simplicity of the illustration, procedure 3400 is described with reference to the communication system architecture of FIG. Procedure 3400 can also be implemented using different architectures. Procedure 3400 may be adapted (for) a scenario in which a first WTRU 1 may trigger a BTM to construct a transaction to a specified blockchain through the 5GS control plane in which the BCN participates. But in order to structure the requested transaction, BTM needs to obtain approval or additional information from another WTRU2 (or another NF, another AF, or another BNA). The entities involved in this procedure include WTRU1, WTRU2, Service AMF, BTM, PCF, LMF, UDSF, BCN, and Notification Target. In this case, either WTRU1 or WTRU2 has BCA / BTC. The BTM can be implemented as a control plane NF or AF. The notification target can be AF or BNA. WTRU1 and WTRU2 can communicate with BTM via the service AMF. Yes Although only one service AMF is shown, WTRU1 and WTRU2 may have different service AMFs. When the BTM is AF, it can communicate with other core network functions (i.e., service AMF, PCF, LMF, and UDSF) via NEF.

[0447] Preprocessing: WTRU1 and WTRU2 can be connected to the service AMF (e.g., in the CM-CONNECTED state). WTRU1 and WTRU2 (e.g., their BCA / BTC) may be logged into or associated with a BTM and may be provided and / or configured to use their functionality. The BTM may be associated with the BCN of the specified blockchain and may be provided and / or configured to request it to construct the transaction to the specified blockchain. The BTM has the address of the NRF and can communicate with it by provision and / or by configuration. The BTM may be provided and / or configured to discover other NFs from the NRF.

[0448] Step 1: Similar to Step 1 in Figure 32 . Since in this scenario the transaction construction can be confirmed with recourse to WTRU2 and / or additional information can be obtained from WTRU2, the identifier of WTRU2 may be included in this step. Alternatively, the identifier of WTRU 2 can be included in the blockchain policy rule maintained locally by the BTM or obtained from the PCF; The trigger request can indicate that the BTM may need to contact another AF (or another NF or another BNA) instead of WTRU2.

[0449] Step 2: Similar to Step 2 in Figure 32 .

[0450] Step 3: Similar to step 3 in Figure 32.

[0451] Step 4: Similar to step 4 in Figure 32.

[0452] Step 5: Based on the trigger request from Step 1 and / or the blockchain policy rules maintained locally by BTM and / or received from PCF, BTM may determine that it needs to obtain additional information or confirmation from WTRU2 (or another NF / AF / BNA) before performing further steps.

[0453] Step 6: The BTM may send a request to WTRU2 to retrieve additional information or obtain its confirmation. The request may include the identifier of WTRU1, the identifier of the BCA in WTRU1, the identifier of the BTC in WTRU1, the identifier of the BTM, the identifier of the BCA in WTRU2, the identifier of the BTC in WTRU2, etc. This request may be relayed by the serving AMF of WTRU2. The BTM may use the identifier of WTRU2 to search for the serving AMF of WTRU2 from the UDM or NRF. If WTRU2 is currently in CM-IDLE state, the serving AMF may call WTRU2 to connect it to the serving AMF and return it to CM-CONNECTED state. The serving AMF may forward the request to WTRU2. If, in Step 1 or Step 5, the BTM is instructed to contact another AF (or another NF / BNA) instead of WTRU2, the BTM may contact the other AF (or another NF / BNA) to obtain its confirmation or additional information.

[0454] Step 7: WTRU2 can receive the request and can send a response to BTM via its service AMF. The response message may include confirmation or additional information as requested by BTM in step 6.

[0455] Step 8: Similar to step 5 in Figure 32.

[0456] Step 9: Similar to step 6 in Figure 32.

[0457] Step 10: Similar to step 7 in Figure 32.

[0458] Step 11: Similar to step 8 in Figure 32.

[0459] Step 12: Similar to step 9 in Figure 32.

[0460] Step 13: Similar to Step 10 in FIG. The identifier of WTRU2 may be included in this step.

[0461] Step 14: Similar to Step 11 in FIG. The notification message may include the identifiers of WTRU1 and WTRU2.

[0462] Step 15: Similar to step 13, the BTM may send a notification to WTRU2 via its service AMF. This notification message may include the same content as is included in the notification in step 13 . [through] [5GS] [data plane] [WTRU] [Triggered Blockchain Transaction Construction]

[0463] 35 illustrates the procedure 3500 for the construction of a blockchain transaction triggered by WTRU. For convenience and simplicity of illustration, procedure 3200 is described with reference to the communication system architecture of FIG. Procedure 3200 can also be implemented using different architectures. Procedure 3200 may be adapted (for) scenarios in which a WTRU may trigger a BTM to construct a transaction to a specified blockchain through the 5GS data plane in which the BCN participates. The entities involved in this procedure include WTRU, service AMF, BTM, UPF, PCF, NF (e.g., LMF), UDSF, BCN, and notification target. In this case, the WTRU has BCA / BTC. The BTM can be implemented as a control plane NF or AF. The notification target can be NF, AF, or BNA. The WTRU communicates with the BTM via its service AMF. When BTM is AF, it can communicate with other core network functions (i.e., service AMF, UPF, PCF, NF, and UDSF) via NEF.

[0464] Preprocessing: The WTRU may be connected to its service AMF (e.g., in the CM-CONNECTED state). A WTRU (e.g., a BCA / BTC thereof) may be logged into or associated with a BTM and may be provided or configured to use its functionality. The BTM may be associated with the BCN of the specified blockchain and may be provided and / or configured to request it to construct the transaction to the specified blockchain. The BTM has the address of the NRF and can communicate with it by provision and / or by configuration. The BTM may be provided and / or configured to discover other NFs from the NRF.

[0465] Steps 1 to 6: Same as steps 1 to 6 in Figure 32.

[0466] Step 7: After determining the BCN, the BTM can determine the UPF through which it can reach the BCN. For this purpose, the BTM can send a request to the SMF to establish a PDU conversation for the BCN. The SMF can determine and select the UPF based on the BCN address provided by the BTM to the SMF. The SMF can establish this PDU conversation for the BTM and transmit conversation information (e.g., the BTM address, the BCN address, and other QoS-related flow information for traffic from the BTM to the BCN) to the selected UPF. The SMF can use the established conversation information and / or the UPF address to send a response back to the BTM.

[0467] Step 8: Same as step 7 in Figure 32.

[0468] Step 9: BTM can use the 5GS data plane to reach BCN. Requests to construct new transactions sent to BCN can be sent to UPF via SMF. UPF can forward the request to BCN. In the other direction, when BCN sends a response back to BTM, the response can be intercepted by UPF and forwarded to BTM via SMF.

[0469] Step 10: Same as step 9 in Figure 32.

[0470] Step 11: Same as step 10 in Figure 32.

[0471] Step 12: Same as step 11 in Figure 32. This notification can be sent to the notification target via the same PDU conversation established as part of step 7.

[0472] 36 illustrates the procedure 3600 for the construction of a blockchain transaction triggered by WTRU. For the convenience and simplicity of the illustration, procedure 3600 is described with reference to the communication system architecture of FIG. Procedure 3600 can also be implemented using different architectures. Procedure 3600 may be adapted (for) scenarios in which a WTRU may trigger a BTM to construct a transaction to a specified blockchain through the 5GS data plane in which the BCN participates. The entities involved in this procedure include WTRU, service AMF, BTM, UPF, PCF, NF (e.g., LMF), UDSF, BCN, and notification target. In this case, the WTRU may have BCA / BTC. The BTM can be implemented as a control plane NF or AF. The notification target can be NF, AF, or BNA. The WTRU may communicate with the BTM via its service AMF. When BTM is AF, it can communicate with other core network functions (i.e., service AMF, UPF, PCF, NF, and UDSF) via NEF.

[0473] Preprocessing: The WTRU may be connected to its service AMF (e.g., in the CM-CONNECTED state). A WTRU (e.g., a BCA / BTC thereof) may be logged into or associated with a BTM and may be provided or configured to use its functionality. The BTM may be associated with the BCN of the specified blockchain and may be provided and / or configured to request it to construct the transaction to the specified blockchain. The BTM has the address of the NRF and can communicate with it by provision and / or by configuration. The BTM may be provided and / or configured to discover other NFs from the NRF.

[0474] Step 1: Same as step 1 in Figure 35 .

[0475] Step 2: Same as Step 2 in Figure 35 .

[0476] Step 3: Same as Step 3 in Figure 35 .

[0477] Step 4: Same as step 4 in Figure 35 .

[0478] Step 5: Same as step 5 in Figure 35 .

[0479] Step 6: Same as step 6 in Figure 35 .

[0480] Step 7: Same as step 8 in Figure 35 .

[0481] Step 8: The BTM may send a request to notify the BCN that the WTRU can access the BCN in Step 10 to store data to the designated blockchain. The request may include the WTRU's identifier and security credentials (e.g., tokens, security certificates) that the BCN can use to authenticate the WTRU when the WTRU accesses the BCN in Step 10.

[0482] Step 9: BTM may send a response to WTRU via its service AMF. The response may include the data to be stored in the designated blockchain and all other necessary information for performing this task via WTRU in step 10. The response may include the same security authentication information included in step 8. Additionally, the address of the BCN may be included in the response message.

[0483] Step 10: The WTRU may send the data received in Step 8 to the BCN in a request via an established PDU conversation. If the PDU conversation has not yet been established, the WTRU may establish a PDU conversation toward the BCN via its service AMF / SMF. The request may include the WTRU1's identifier and the same security authentication information received in Step 9. The BCN may compare the WTRU's identifier with the security credentials received as in Steps 10 and 8. If the WTRU's identifier matches the security credentials received as in Steps 10 and 8 (e.g., they are the same, or one can decrypt the other), the BCN may authorize the request. The BCN may (i) construct a new transaction as requested, (ii) store the new transaction in the designated blockchain, and (iii) send a response back to the WTRU via the same UPF.

[0484] Steps 11 and 12: The WTRU may send a notification to the BTM indicating all relevant information relating to the transaction constructed in step 10. Similar to step 9 in Figure 32, the BTM may send the update to the UDSF. Alternatively, instead of the BTM sending the update to the UDSF, the WTRU may send the same update to the UDSF via the WTRU's service AMF.

[0485] Step 13: The WTRU may send a notification to the notification target. This notification may include all relevant information relating to the transaction constructed in step 10. Alternatively, the BTM may send this notification, which it received in step 10, to the notification target. [in conclusion]

[0486] While features and elements in specific combinations are provided above, those skilled in the art will understand that each feature or element can be used alone or in combination with other features and elements. This disclosure is not intended to be limited to specific embodiments of various forms described in this application. Many modifications and variations can be made without departing from its spirit and scope, which will be apparent to those skilled in the art. Thus, unless explicitly stated otherwise, elements, actions, or instructions used in the description of this application should not be construed as essential or necessary to the invention. In addition to those enumerated herein, functionally equivalent methods and apparatus within the scope of this disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only to the language of the appended claims, together with the full scope of their equivalents. It should be understood that this disclosure is not limited to any particular method or system.

[0487] For simplicity, the foregoing embodiments pertain to the terminology and structure of infrared-capable devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems and can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0488] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or "imagery" may mean any of a snapshot, a single image, and / or multiple images displayed on a time-based basis. As another example, when referenced herein, the term "user equipment" and its abbreviation "UE", the term "remote", and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmitting and / or receiving unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a device having wireless and / or wired (e.g., wired) capabilities, particularly configured with some or all of the structure and functionality of a WTRU; (iii) a device having wireless and / or wired capabilities, configured with less than all the structure and functionality of a WTRU; or (iv) similar. Examples of any WTRUs described herein are represented by Figures 1A through 1D provided herein. As another example, the various disclosed embodiments described herein utilize a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be used, and accordingly, some or all of the disclosed embodiments can be modified without excessive experimentation. Examples of such other devices may include drones or other devices that configure streaming information for providing adapted real-world experiences.

[0489] Additionally, the methods provided herein can be incorporated into computer-readable media for use in computer programs, software, or firmware implementations executed by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-RAM discs and digital versatile disks, DVDs). A processor associated with the software can be used to implement radio frequency transceivers for use in WTRUs, UEs, terminals, base stations, RNCs, or any host computer.

[0490] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the various applicable embodiments, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the following claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery pack and the like) providing any suitable voltage.

[0491] Furthermore, in the embodiments provided above, the terms "processing platform," "computing system," "controller," and other devices containing a processor" are mentioned. These devices may contain at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memory. Such actions and operations or instructions may be referred to as "executed," "computer-executed," or "CPU-executed."

[0492] Those skilled in the art will understand that actions and symbolically represented operations or instructions include manipulating electrical signals by the CPU. An electrical system represents the result of which can cause changes or degradation of electrical signals and the maintenance of data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and other signal processing. The memory location maintaining the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs mentioned above, and other platforms and CPUs may support the provided methods.

[0493] Data bits may also be stored on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems readable by the CPU. Computer-readable media may include cooperative or interconnected computer-readable media that exist exclusively on the processing system or are distributed across multiple interconnected processing systems, either locally or remotely. It should be understood that the embodiments are not limited to the memory mentioned above, and other platforms and memories may support the provided methods.

[0494] In one illustrative embodiment, any of the operations, procedures, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by a processor of an action unit, network element, and / or any other computing device.

[0495] There is very little distinction between hardware and software implementations of the system. The purpose of hardware or software is often (but not always; in certain contexts, the choice between hardware and software can become significant) a design choice representing a trade-off between cost and efficiency. Various carriers (e.g., hardware, software, and / or firmware) may exist by which the programs and / or systems and / or other technologies described herein are implemented, and a preferred carrier may vary depending on the context in which the programs and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are paramount, the implementer may choose a carrier that is primarily hardware and / or firmware. If flexibility is paramount, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0496] The foregoing embodiments have been described using block diagrams, flowcharts, and / or examples to illustrate various embodiments of the apparatus and / or program. Where such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that the functions and / or operations within such block diagrams, flowcharts, or examples can be implemented individually or collectively by various hardware, software, firmware, or virtually any combination thereof. In one embodiment, several parts of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated circuit forms. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be implemented, either wholly or partially, in an integrated circuit equivalent as one or more computer programs (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or any combination thereof, and will recognize that designing the circuit system and / or writing the code for the software and / or firmware will be entirely within the scope of the art to which this disclosure pertains. Additionally, those skilled in the art will understand that the mechanisms of the subject matter disclosed herein can be distributed as program products in various forms, and will understand that the illustrative embodiments of the subject matter disclosed herein are applied independently of the specific type of signal-bearing media used for actual implementation. Examples of signal-carrying media include, but are not limited to, the following: recordable media (such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.) and transmission media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0497] Those skilled in the art will recognize that the devices and / or programs described herein are common in the field, and engineering practices are used below to integrate such devices and / or programs into a data processing system. That is, at least a portion of the devices and / or programs described herein can be integrated into a data processing system through reasonable experimentation. Those skilled in the art will recognize that a typical data processing system generally includes a system unit housing, a video display device, memory (such as volatile and non-volatile memory), a processor (such as a microprocessor and a digital signal processor), a computing entity (such as an operating system, driver, graphical user interface, and application), one or more interactive devices (such as a touchpad or screen), and / or a control system including one or more feedback loops and control motors (e.g., feedback sensing of position and / or speed, movement and / or adjustment components, and / or quantity control motors). A typical data processing system can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0498] The objects described herein sometimes refer to different components contained within or connected to such other components. It should be understood that the architectures depicted are merely examples, and in fact, many other architectures can be implemented to achieve the same functionality. Conceptually, any configuration of components achieving the same functionality is effectively "associated" so that the desired functionality can be realized. Therefore, any two components in this document combined to achieve a particular functionality can be considered as "associated with" each other, so that the desired functionality can be achieved regardless of the architecture or intermediate components. Similarly, any two such associated components can be considered as "operably connected" or "operably coupled" to achieve the desired functionality, and any two components that can be suchly associated can be considered as "operably coupled" to each other to achieve the desired functionality. Specific examples of operable coupling include, but are not limited to, components that can be physically paired and / or physically interact and / or wirelessly interact and / or logically interact and / or logically interact.

[0499] Regarding the use of any substantial plural and / or singular terms in this document, those skilled in the art can appropriately convert from plural to singular and / or from singular to plural forms depending on the context and / or application. For clarity, various singular / plural arrangements are explicitly described herein.

[0500] Those skilled in the art will understand that the terms used herein and particularly in the appended claims (e.g., the subject of the appended claims) are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "include" should be interpreted as "includes but not limited to," etc.). Those skilled in the art will further understand that if a specific number described in the introduced claim is intentional, this intention will be explicitly stated in the claim, and the absence of such a statement indicates the absence of such intention. For example, the term "single" or similar language may be used where only one item is intended. For further understanding, the appended claims and / or the description herein may contain the introductory phrases "at least one" and "one or more" to introduce the claim description. However, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles (such as "a" or "an" (e.g., "a" or "an" should be interpreted as meaning "at least one" or "one or more")), the use of such phrases should not be interpreted as meaning that the claim statement introduced by the indefinite article "a" or "an" limits any particular claim containing such an introductory claim statement to an embodiment containing only one such statement. This is also true for the use of definite articles used to introduce claim statements. Furthermore, even if a specific number of claim statements is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least that number of statements (e.g., a bare recitation of "two statements" without other modifiers means at least two statements, or two or more statements).Furthermore, in cases where a convention similar to "at least one of A, B, and C, etc." is used, this construction is generally intended to make the convention understandable to those with ordinary knowledge in the art (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having A and B together, having A and C together, having B and C together, and / or having A, B, and C together). In cases where conventions such as "at least one of A, B, or C" are used, this construction is generally intended to be understood to a degree that a person skilled in the art would grasp the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having A and B together, having A and C together, having B and C together, and / or having A, B, and C together). A person skilled in the art will further understand that any transitional word or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to imply the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" would be understood to include the possibility of "A" or "B" or "A and B". Furthermore, as used herein, the term "any of" following a list of multiple items and / or multiple categories of items is intended to individually or in combination with other items or categories of items to include "any of," "any combination of," "any multiple of," and / or "any combination of multiples of." Additionally, as used herein, the term "set" is intended to include any number of items (including zero). Furthermore, as used herein, the term "number" is intended to include any number (including zero).

[0501] Furthermore, since the features or characteristics of this disclosure are described in accordance with the Markush group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member or subgroup of the Markush group.

[0502] As will be understood by one of ordinary skill in the art, for any and all purposes, such as providing a written description, all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily considered sufficient to describe and enable the decomposition of the same scope into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, the scopes discussed herein can be readily decomposed into the lower third, middle third, and upper third, etc. Also, as will be understood by one of ordinary skill in the art, all language such as "up to," "at least," "greater than," "less than," and the like includes the stated numbers and can refer to a scope that can subsequently be decomposed into subscopes as discussed above. Finally, as will be understood by one of ordinary skill in the art, a scope includes individual members. Thus, for example, a group having 1 to 3 units refers to a group having 1, 2, or 3 units. Similarly, groups with 1 to 5 units refer to groups with 1, 2, 3, 4, or 5 units and so on.

[0503] Furthermore, unless the effect is stated, the scope of the patent application should not be interpreted as limited to the order or elements provided. Additionally, the use of the phrase "means for" in any claim is intended to invoke 25 USC §112, ¶ 6 or the claim format of means-plus-function, and any claim without the phrase "means for" is not intended to do so.

[0504] 0: Steps 1: Steps 2: Steps 3: Steps 3': Steps 4: Steps 5: Steps 6: Steps 7: Steps 8: Steps 9: Steps 10: Steps 11: Steps 12: Steps 13: Steps 14: Steps 15: Steps 16: Steps 17: Steps 17': Steps 18: Steps 19: Steps 20: Steps 21: Steps 22: Steps 23: Steps 25: Steps 26: Steps 100: Communication System 102:WTRU 102a: Wireless Transmit / Receive Unit (WTRU) 102b: Wireless Transmit / Receive Unit (WTRU) 102c: Wireless Transmit / Receive Unit (WTRU) 102d: Wireless Transmit / Receive Unit (WTRU) 104: Radio Access Network (RAN) 106: Core Network (CN) 108: Public Switched Telephone Network (PSTN) 110: Internet 112: Internet 113: Radio Access Network (RAN) 114:RAN 114a: Base Station 114b: Base Station 115: Core Network (CN) / Air Interface 116: Empty Intermediate Surface 117: Empty Intermediate Surface 118: Processor 120: Transceiver 122: Transmit / receive element 124: Speaker / Microphone 126: Keyboard 128: Monitor / Touchpad 130: Non-removable memory 132: Removable Memory 134: Power Supply 136: Global Positioning System (GPS) Chipset 138: Peripheral Equipment 140:BTM / BCN 140-1:BTM / BCN 140-2:BTM 141:BCN / BNA / BTM 141-1:BCN / BTM 141-2:BCN 142:BTC / BCA 142-1:BTC 142-2:BTC 143: BCA / BTC / BTM 143a:BCA 143b:BCA 144:BNA / DPP 145:DPP 146: EDS / DPP / BTM 160a:eNode-B 160b:eNode-B 160c:eNode-B 162: Movement Management Gateway (MME) / AMF 164: Service Gateway (SGW) 166: Packet Data Network (PDN) Gateway / PGW 180a:gNB 180b:gNB 180c:gNB 182a: Access and Mobility Management Function (AMF) 182b: Access and Mobility Management Function (AMF) 183a: Conversation Management Function (SMF) 183b: Conversation Management Function (SMF) 184: User Plane Function (UPF) 184a: User Plane Function (UPF) 184b: User Plane Function (UPF) 185a: Data Network (DN) 185b: Data Network (DN) 1400: Architecture 1500: Architecture 1600: Program 1700: Program 1800: Program 1900: Program 2000: Program 2100: Program 2200: Program 2400: Program 2500: Program 2600: Program 2900: Program 3000: Program 3100: Program 3200: Program 3300: Program 3400: Program 3500: Program 3600: Program AF: Application Functions AMF: Access and Mobility Management Function AUSF: Authentication Server Functionality BCA: Blockchain Client Application BCN: Blockchain Node BCNx:BCN BCNy:BCN BCNz:BCN BNA: Blockchain Network Application BNWK: Blockchain Network BTC: Blockchain Trading Clients BTM: Blockchain Transaction Manager CHF: Paid Features CN: Core Network DN: Data Network DPP: Data and Policy Provider EDS: External Data Storage GMLC: Entity LADN1: Regional Data Network Le: Reference point MME: Mobility Management Gateway N1: Reference point N2: Interface N3: Interface N4: Interface N6: Interface N11: Interface N51: Reference Point N52: Reference Point NEF: Online Disclosure Function NF: Network Functions NF1: Network Functions NF2: Network Functions NF3: Network Functions NL1: Reference Point NL2: Reference Point NL5: Reference Point NL6: Reference Point NRF: Network Repository Function NSSF: Network Slice Selection Function NWDAF: Network Data Analysis Function PCF: Policy Control Function PDN: Packet Data Network PSTN: Public Switched Telephone Network RA1: Login Area RA2: Login Area RAN: Radio Access Network (R)AN: Node RSU1: Roadside Unit RSU2: Roadside Unit S1: Interface SMF: Dialogue Management Function TA1: Tracking Zone TA2: Tracking Zone TA3: Tracking Zone TA4: Tracking Zone TA5: Tracking Zone TA6: Tracking Zone TA7: Tracking Zone TA8: Tracking Zone TA9: Tracking Zone UDM: Unified Data Management UDR: Unified Data Repository UDSF: Unstructured Data Storage Function UPF: User Plane Function WTRU: Wireless Transmitter / Receiver Unit WTRU1: Wireless Transmitter / Receiver Unit WTRU2: Wireless Transmitter / Receiver Unit X2: Interface Xn: Interface

Claims

1. A method for transaction management in a distributed ledger-enabled system, implemented in a first device including a circuit system comprising a transmitter, a receiver, and a processor, the method comprising: receiving at least one first transmission from at least one second device via either a wired or wireless transmission medium, wherein the at least one first transmission includes content and first information, wherein the first information indicates: (i) a request to add the content to a distributed ledger, (ii) an identifier of a client application corresponding to the at least one second device, the client application being associated with the request, and (iii) identifying second information of the distributed ledger, wherein the content includes at least one of first data and third information, the third information indicating a locator for retrieving the second data from a first repository other than the distributed ledger; generating a digital transaction record for fourth information, wherein the fourth information includes: (i) at least some of the first data, (ii) at least some of the second data, or (iii) at least some of the first data and at least some of the second data; The first information is used to determine a node of a distributed ledger; and at least one second transmission is transmitted to the at least one second device via either the wired or wireless transmission medium, wherein the at least one second transmission includes: (i) fifth information indicating a response to a request, (ii) sixth information indicating a sequence number associated with the digital transaction record stored in the distributed ledger, and (iii) seventh information indicating an indicator / locator of third data associated with the digital transaction record and stored in a second repository outside the distributed ledger, wherein the third data includes: (i) at least some of the first data, (ii) at least some of the second data, or (iii) at least some of the first data and the second data.

2. The method of claim 1, comprising: transmitting the digital transaction record to the node of the distributed ledger via either the wired or wireless transmission medium.

3. The method of claim 1, comprising: transmitting the third data to the second storage via either the wired or wireless transmission medium.

4. The method of claim 1, wherein the node of the distributed ledger is a first node of the distributed ledger, the method further comprising: receiving an acknowledgment that the digital transaction record has been successfully inserted into the distributed ledger, wherein the acknowledgment is received from any one of the first node of the distributed ledger, a second node of the distributed ledger, and a second device associated with at least one of the first node and the second node.

5. The method of request item 1, which includes: notifying one or more recipients of a status of the digital transaction record.

6. The method of claim 1, wherein generating a digital transaction record comprises: generating the digital transaction record based on the first information and at least one of the following: (i) one or more policy rules and (ii) a hash value of the third information.

7. The method of claim 6, wherein the one or more policy rules include either a first policy rule or a second policy rule, the first policy rule controlling (i) whether at least some of the first data, (ii) at least some of the second data, or (iii) at least some of the first data and some of the second data are added to the distributed ledger, and the second policy rule controlling how (i) at least some of the first data, (ii) at least some of the second data, or (iii) at least some of the first data and at least some of the second data are added to the distributed ledger.

8. The method of claim 1, wherein determining a node of a distributed ledger comprises: determining the node of the distributed ledger based at least in part on the proximity of the first device to the node of the distributed ledger.

9. The method of claim 1, wherein the first information includes any of the following: (i) a number of transactions to be constructed, (ii) an application category associated with each of the one or more sources, (iii) an application name associated with each application, (iv) security credential information for each of the one or more sources, (v) a category of transactions to be constructed, (vi) a maximum transaction construction time, (vii) a maximum transaction waiting time, (viii) a transaction construction priority, (ix) a transaction inclusion priority, (x) an address of each of the one or more recipients to whom a status of the transaction is to be notified, (xi) a type of the distributed ledger, (xii) a hash function, (xiii) an instruction of at least one of the one or more policy rules, and (xiv) security credential information of the first device.

10. The method of claim 1, wherein generating the digital transaction record and determining at least one of the nodes of the distributed ledger are based on one or more blockchain transaction policy rules.

11. A first apparatus for transaction management in a distributed ledger-enabled system, the first apparatus comprising a circuit system including a transmitter, a receiver, a processor, and a memory, the first apparatus configured to: receive at least one first transmission from at least one second apparatus via either a wired or wireless transmission medium, wherein the at least one first transmission includes content and first information, wherein the first information indicates: (i) a request to add the content to a distributed ledger, (ii) an identifier of a client application corresponding to the at least one second apparatus, the client application being associated with the request, and (iii) second information identifying the distributed ledger, wherein the content includes at least one of first data and third information, the third information indicating a locator for retrieving the second data from a first repository other than the distributed ledger; and generate a digital transaction record for fourth information, wherein the fourth information includes: (i) at least some of the first data, (ii) at least some of the second data, or (iii) at least some of the first data and at least some of the second data; The first information is used to determine a node of a distributed ledger; and at least one second transmission is transmitted to the at least one second device via either the wired or wireless transmission medium, wherein the at least one second transmission includes: (i) fifth information indicating a response to a request, (ii) sixth information indicating a sequence number associated with the digital transaction record stored in the distributed ledger, and (iii) seventh information indicating an indicator / locator of third data associated with the digital transaction record and stored in a second repository outside the distributed ledger, wherein the third data includes: (i) at least some of the first data, (ii) at least some of the second data, or (iii) at least some of the first data and the second data.

12. The first device of claim 11, wherein the circuit system is configured to: (i) generate the digital transaction record based on one or more blockchain transaction policy rules and (ii) determine the node of the distributed ledger based on the one or more blockchain transaction policy rules.

13. The first apparatus of claim 11, wherein the circuit system is configured to transmit the digital transaction record to the node of the distributed ledger via either the wired or wireless transmission medium.

14. The first device of claim 13, wherein the circuit system is configured to transmit the third data to the second storage via either the wired or wireless transmission medium.

15. The first device of claim 11, wherein the node of the distributed ledger is a first node of the distributed ledger, wherein the circuit system is configured to: receive an acknowledgment that the digital transaction record has been successfully inserted into the distributed ledger, wherein the acknowledgment is received from any of the first node of the distributed ledger, a second node of the distributed ledger, and a second device associated with at least one of the first node and the second node.

16. The first means as claimed in claim 11, wherein the circuit system is configured to notify one or more recipients of a status of the digital transaction record.

17. The first device of claim 11, wherein the circuit system is configured to generate the digital transaction record based on the first information and at least one of the following: (i) one or more policy rules and (ii) a hash value of the third data.

18. The first device of claim 17, wherein the one or more policy rules include either a first policy rule or a second policy rule, the first policy rule being used to control (i) whether at least some of the first data, (ii) at least some of the second data, or (iii) at least some of the first data and some of the second data are added to the distributed ledger, and the second policy rule being used to control how (i) at least some of the first data, (ii) at least some of the second data, or (iii) at least some of the first data and at least some of the second data are added to the distributed ledger.

19. The first device as claimed in claim 11, wherein the circuit system is configured to determine the node of the distributed ledger based at least in part on the proximity of the first device to the node of the distributed ledger.

20. The first device as claimed in claim 11, wherein the first information includes any of the following: (i) a number of transactions to be constructed, (ii) an application category associated with each of the one or more sources, (iii) an application name associated with each client application, (iv) security credential information for each of the one or more sources, (v) a category of transactions to be constructed, (vi) a maximum transaction construction time, (vii) a maximum transaction waiting time, (viii) a transaction construction priority, (ix) a transaction inclusion priority, (x) an address of each of the one or more recipients to whom a status of the transaction is to be notified, (xi) a type of the distributed ledger, (xii) a hash function, (xiii) an instruction of at least one of the one or more policy rules, and (xiv) the security credential information of the first device.

Images