WO2021181910A1 - 通信装置、データ記録方法、及び非一時的なコンピュータ可読媒体 - Google Patents

通信装置、データ記録方法、及び非一時的なコンピュータ可読媒体 Download PDF

Info

Publication number
WO2021181910A1
WO2021181910A1 PCT/JP2021/002237 JP2021002237W WO2021181910A1 WO 2021181910 A1 WO2021181910 A1 WO 2021181910A1 JP 2021002237 W JP2021002237 W JP 2021002237W WO 2021181910 A1 WO2021181910 A1 WO 2021181910A1
Authority
WO
WIPO (PCT)
Prior art keywords
plane
data
communication
ssh
wireless
Prior art date
Application number
PCT/JP2021/002237
Other languages
English (en)
French (fr)
Inventor
昌志 中田
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to EP21768337.4A priority Critical patent/EP4007350A4/en
Priority to JP2022505816A priority patent/JP7287569B2/ja
Priority to CN202180020566.9A priority patent/CN115280736A/zh
Priority to US17/637,159 priority patent/US12015523B2/en
Publication of WO2021181910A1 publication Critical patent/WO2021181910A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/06—Generation of reports
    • H04L43/062—Generation of reports related to network traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/12—Network monitoring probes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2885—Hierarchically arranged intermediate devices, e.g. for hierarchical caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/06—Testing, supervising or monitoring using simulated traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H04W88/085—Access point devices with remote components

Definitions

  • This disclosure relates to communication devices, data recording methods, and programs.
  • the O-RAN front hall specifications specified in the O-RAN (Open-Radio Access Network) alliance include O-RU (Radio Unit), which corresponds to the radio section, and O-DU (Distributed Unit), which corresponds to the baseband section. It stipulates the specifications of the front hall between.
  • O-RAN front hole specification is to facilitate connection between the O-DU vendor and the O-RU of a different vendor, and to realize multi-vendor radio access networks.
  • Non-Patent Document 1 discloses a procedure for verifying interoperability between O-DU and O-RU, an analysis method, and the like.
  • an FH (Fronthaul) Protocol analyzer is connected between the O-DU and the O-RU, and data transmitted between the O-DU and the O-RU is transmitted using the FH Protocol analyzer. It is disclosed to analyze.
  • ORAN-WG4.IOT.0-v01.00 O-RAN Fronthaul Working Group Fronthaul Interoperability Test Specification (IOT)
  • the FH Protocol analyzer disclosed in Non-Patent Document 1 can analyze only the data that can be acquired before the SSH (Secure Shell) connection between the O-DU and the O-RU is established. .. That is, after the SSH connection is established between O-DU and O-RU, the FH Protocol analyzer cannot acquire the information transmitted via SSH. Therefore, the FH Protocol analyzer has a problem that it cannot analyze the data transmitted between the O-DU and the O-RU over the SSH connection.
  • SSH Secure Shell
  • An object of the present disclosure is to provide a communication device, a data recording method, and a program capable of acquiring data transmitted by an SSH connection after an SSH (Secure Shell) connection is established between the wireless unit and the baseband unit. There is.
  • SSH Secure Shell
  • the communication device establishes a first SSH (Secure Shell) connection between a communication terminal and a wireless device that performs wireless communication, and baseband processing for signals used in the wireless communication.
  • the communication unit that establishes a second SSH connection with the control device that performs the operation, and the management plane data received from the wireless device via the first SSH connection or the second SSH connection from the control device. It is provided with a data recording unit that records the data of the management plane received via the above.
  • a first SSH (Secure Shell) connection is established between a communication terminal and a wireless device that performs wireless communication, and a base band relating to a signal used in the wireless communication is established.
  • a second SSH connection is established with the control device that performs processing, and the data of the management plane received from the wireless device via the first SSH connection or from the control device via the second SSH connection. The data of the management plane received is recorded.
  • the program according to the third aspect of the present disclosure establishes a first SSH (Secure Shell) connection between a communication terminal and a wireless device that performs wireless communication, and performs baseband processing on signals used in the wireless communication.
  • a second SSH connection is established with the control device to be performed, and the data of the management plane received from the wireless device via the first SSH connection or received from the control device via the second SSH connection.
  • FIG. It is a block diagram of the communication apparatus which concerns on Embodiment 1.
  • FIG. It is a block diagram of the communication system which concerns on Embodiment 2.
  • FIG. It is a figure which shows the protocol stack of M-Plane which concerns on Embodiment 2.
  • FIG. It is a figure which shows the protocol stack of C / U-Plane which concerns on Embodiment 2.
  • FIG. It is a figure which shows the protocol stack of S-Plane which concerns on Embodiment 2.
  • FIG. It is a figure which shows the Star-up sequence about M-Plane which concerns on Embodiment 2.
  • FIG. It is a figure which shows the SSH connection which concerns on Embodiment 2.
  • FIG. It is a block diagram of the communication apparatus which concerns on Embodiment 1.
  • FIG. It is a block diagram of the communication system which concerns on Embodiment 2.
  • FIG. It is a figure which shows the protocol
  • FIG. 2 It is a figure which shows the flow defined between FH-Proxy which concerns on Embodiment 2, and O-RU and O-DU. It is a figure which shows the flow of the process which is classified into Type B which concerns on Embodiment 2.
  • FIG. It is a block diagram of FH-Proxy according to Embodiment 3. It is a figure which shows the Ethernet header which concerns on Embodiment 3. It is a figure which shows the eCPRI Transport header which concerns on Embodiment 3. It is a figure which shows the Section Type 1 message of C-Plane which concerns on Embodiment 3. FIG. It is a figure which shows the Section Type 3 message of C-Plane which concerns on Embodiment 3.
  • FIG. 1 It is a figure which shows Section Type 1 and 3 message of U-Plane which concerns on Embodiment 3.
  • FIG. It is a figure which shows the modification of the communication system of Embodiments 2 and 3.
  • the communication device 10 may be a computer device that operates by executing a program.
  • the communication device 10 has a communication unit 11 and a data recording unit 12.
  • the communication unit 11 and the data recording unit 12 may be software or modules whose processing is executed by the processor executing a program stored in the memory.
  • the communication unit 11 establishes a first SSH connection between the communication terminal 40 and the wireless device 20 that performs wireless communication, and establishes a first SSH connection with the control device 30 that performs baseband processing on signals used in the wireless device 20. Establish 2 SSH connections.
  • the communication terminal 40 may be, for example, a smartphone terminal, an IoT (Internet of Things) terminal, an MTC (Machine Type Communication) device, or the like.
  • the radio device 20 may be, for example, an O-RU entity (hereinafter referred to as O-RU) defined in the O-RAN alliance.
  • the control device 30 may be, for example, an O-DU entity (hereinafter referred to as O-DU) defined in the O-RAN alliance.
  • An entity may be referred to as a node or node device.
  • the communication unit 11 establishes a first SSH connection between the wireless device 20 and the wireless device 20 by performing authentication using the public key A. Further, the communication unit 11 establishes a second SSH connection between the control device 30 and the control device 30 by performing authentication using the public key B.
  • the establishment of the SSH connection is not limited to the method using the public key, and may be performed by other methods.
  • the data recording unit 12 records the data of the management plane received from the wireless device 20 via the first SSH connection. Further, the data recording unit 12 records the data of the management plane received from the control device 30 via the second SSH connection.
  • the communication device 10 terminates the first SSH connection and the second SSH connection, respectively. Therefore, the data recording unit 12 can decrypt the encrypted data received via the first SSH connection or the second SSH connection. That is, the data recording unit 12 holds data in a format capable of analyzing the header and payload of each layer of data.
  • the management plane handles, for example, data or messages used by the control device 30 or NMS (Network Management System) to maintain or monitor the wireless device 20.
  • the data of the management plane is the data transmitted and received in the management plane.
  • the communication device 10 can establish an SSH connection with each of the wireless device 20 and the control device 30. Therefore, in general, the data of the management plane transmitted between the wireless device 20 and the control device 30 via the SSH connection can be held in a format that enables analysis of the header and the payload. As a result, the communication device 10 can acquire the data transmitted after the SSH connection is established between the wireless device 20 and the control device 30, and can analyze the acquired data.
  • the communication system of FIG. 2 mainly shows the system configuration specified in the O-RAN alliance.
  • the communication system of FIG. 2 has an FH (Fronthaul) -Proxy entity (hereinafter referred to as FH-Proxy) 50, an O-RU60, and an O-DU70.
  • FH-Proxy FH-Proxy entity
  • the FH-Proxy 50 corresponds to the communication device 10 in FIG.
  • the O-RU60 corresponds to the wireless device 20 of FIG.
  • the O-DU 70 corresponds to the control device 30 of FIG.
  • M (Management) -Plane, C (Control) -Plane, U (User) -Plane, and S (Synchronization) -Plane are set between FH-Proxy50 and O-RU60. Further, M-Plane, C-Plane, U-Plane, and S-Plane are also set between the FH-Proxy 50 and the O-DU 70.
  • the FH-Proxy50 behaves pseudo-as O-DU with respect to O-RU60 and pseudo-behaves as O-RU with respect to O-DU70.
  • M-Plane is a protocol for transferring monitoring signals used to monitor or maintain equipment.
  • FIG. 3 shows the protocol stack of M-Plane.
  • M-Plane supports a protocol stack that transmits signals used in NETCONF (NETwork CONFigutation protocol) using Ethernet (registered trademark) / IP / TCP (Transmission Control Protocol) / SSH.
  • NETCONF NETwork CONFigutation protocol
  • Ethernet registered trademark
  • IP / TCP Transmission Control Protocol
  • C-Plane is a protocol for transferring control signals.
  • U-Plane is a protocol for transferring user data.
  • FIG. 4 shows the C-Plane and U-Plane protocol stacks.
  • C-Plane and U-Plane support a protocol stack that transmits signals used in eCPRI (ehnanced Common Public Radio Interface) or RoE (Radio over Ethernet) using Ethernet / IP / UDP (User Datagram Protocol). ing.
  • the C-Plane and U-Plane may support a protocol stack that directly transmits the signals used in eCPRI or RoE using Ethernet.
  • S-Plane is a protocol for realizing synchronization between devices. Specifically, FIG. 5 shows the S-Plane protocol stack. S-Plane supports a protocol stack that transmits signals used in PTP (Precision Time Protocol) and SyncE using Ethernet.
  • PTP Precision Time Protocol
  • FIG. 6 shows, for example, a procedure from the activation of the O-RU60, which is the management target of the O-DU70, until the management of the O-RU60 by the O-DU70 becomes possible. Management may be paraphrased as monitoring.
  • the O-DU70 which is a network device that manages the O-RU60, corresponds to the NETCONF client, and the O-RU60 to be managed corresponds to the NETCONF server.
  • FIG. 6 shows that each process is executed between the NETCONF client corresponding to O-DU 70 and the NETCONF server corresponding to O-RU 60.
  • the communication system used in the second embodiment has a configuration in which the FH-Proxy 50 is arranged between the O-DU 70 and the O-RU 60. Therefore, FIG. 6 shows the Start-up process executed between the NETCONF client, the FH-Proxy 50, and the NETCONF server.
  • FH-Proxy50, O-RU60, and O-DU70 execute the processes from Transport Layer Initialization to SSH Secure Connection Established, which are classified into Type A shown in FIG.
  • the processing classified into Type A is a processing in which the processing between O-RU60 and FH-Proxy50 and the processing between O-DU70 and FH-Proxy50 are performed independently.
  • the FH-Proxy 50 operates as a NETCONF client when communicating with the O-RU 60 which is a NETCONF server.
  • the FH-Proxy 50 operates as a NETCONF server when communicating with the O-DU 70, which is a NETCONF client.
  • SSH connections are established between FH-Proxy50 and O-RU60 and between FH-Proxy50 and O-DU70, respectively, as shown in FIG. Will be done.
  • FH-Proxy50, O-RU60, and O-DU70 also set the Transport Layer by executing the processing classified into Type A.
  • the Transport Layer setting may be, for example, setting an IP address or an Ethernet address, which is a Transport Layer address, in each device.
  • the FH-Proxy 50 sets the Transport Layer address for communicating with the O-DU 70 to a Transport Layer address different from the Transport Layer address for communicating with the O-RU 60.
  • the Transport Layer setting and SSH connection establishment are performed between the link between O-RU60 and FH-Proxy50, and between O-DU70 and FH-Proxy50. It is executed individually at the link of.
  • the FH-Proxy50, O-RU60, and O-DU70 execute the processes from NETCONF Capability discovery to Configuration the O-RU operational parameters, which are classified into Type B shown in FIG.
  • the process classified into Type B is a process executed between the NETCONF server O-RU60 and the NETCONF client O-DU70 via the FH-Proxy50.
  • Each process of the Start-up sequence shown in FIG. 6 is executed using the message specified in NETCONF.
  • the set of parameters set in the message is specified by the Yang module shown in FIG.
  • the parameter described as A is the parameter used in the Type A process, and the other parameters are used in the Type B process.
  • the parameter described as O-RU Capability indicates the Capability information supported by O-RU60.
  • the message specified in NETCONF for example, an rpc message, an rpc-reply message, or a notification message is used.
  • the O-DU70 and O-RU60 use these messages to set parameters (edit-config) or acquire parameters (get-config).
  • O-RU60 and FH-Proxy50 set the MAC address specified in the Transport flow of the o-ran-processing element of the Yang module.
  • the addresses at both ends of the flow defined between the O-RU60 and the FH-Proxy50 are defined.
  • Each address can be the Source address and Destination Address of the data transmitted between the O-RU 60 and the FH-Proxy 50.
  • the O-DU70 and the FH-Proxy50 also set the MAC address specified in the Transport flow of the o-ran-processing element of the Yang module in the same manner.
  • the addresses at both ends of the flow defined between the O-RU60 and the FH-Proxy50 are defined.
  • Each address can be the Source address and Destination Address of the data transmitted between the O-DU 70 and the FH-Proxy 50.
  • FIG. 9 shows a flow defined using the address information specified in the o-ran-processing-element.
  • FIG. 9 shows that the FH-Proxy 50 is located between the O-RU61, O-RU62, and O-RU63 and the O-DU71, O-DU72, and O-DU73.
  • the number of O-DUs and O-RUs connected to the FH-Proxy 50 is not one each, but is plural as shown in FIG. 9, and does not have to be the same.
  • FH-Proxy50 defines Address-1 of O-DU71 and Address-1A of FH-Proxy50 as flow1 and communicates with O-DU71. flow may be referred to as Transport flow. Similarly, FH-Proxy50 defines Address-2 of O-DU72 and Address-2A of FH-Proxy50 as flow2, and communicates with O-DU72. FH-Proxy50 defines Address-3 of O-DU73 and Address-3A of FH-Proxy50 as flow3, and communicates with O-DU73. FH-Proxy50 defines Address-4 of O-RU61 and Address-4A of FH-Proxy50 as flow4, and communicates with O-RU61.
  • FH-Proxy50 defines Address-5 of O-RU62 and Address-5A of FH-Proxy50 as flow5, and communicates with O-RU62.
  • FH-Proxy50 defines Address-6 of O-RU63 and Address-6A of FH-Proxy50 as flow6, and communicates with O-RU63.
  • FH-Proxy50 verifies using Address-1A and Address-4A.
  • the FH-Proxy50 verifies the interconnection between O-DU71 and O-RU61, it verifies using flow1 and flow4.
  • the FH-Proxy50 verifies using Address-2A and Address-6A.
  • the FH-Proxy50 When executing Type B processing, the FH-Proxy50 terminates and converts the Transport Layer address as shown in FIG. 9, but makes the NETCONF layer, which is the upper layer, transparent.
  • the FH-Proxy50 records information transmitted in the NETCONF layer. In other words, the FH-Proxy50 records the information transmitted in the NETCONF layer as a log and visualizes the information transmitted in the NETCONF layer. Further, the FH-Proxy 50 also records the information transmitted in the NETCONF layer as a log when executing the Type A process, and visualizes the information transmitted in the NETCONF layer.
  • the process related to Retrieval of O-RU Information is a process performed for the O-DU 70 to acquire the parameters related to the O-RU 60.
  • the O-DU 70 transmits a get-config intended to acquire parameters and an rpc message in which a ru-id indicating the parameters to be acquired is set to the FH-Proxy 50 (S11).
  • the FH-Proxy50 changes the Transport Layer address of the received rpc message (S12). Specifically, the destination MAC address of the rpc message is changed to the MAC address of O-RU60, and the source MAC address is changed to the MAC address of FH-Proxy50.
  • the FH-Proxy 50 changes the ietf-interface, o-ran-interface, and o-ran-processing-element used in the processing classified into Type A.
  • the FH-Proxy 50 transfers the rpc message whose Transport Layer address has been changed to the O-RU 60 (S13). At this time, the FH-Proxy50 transmits the NETCONF layer information of the rpc message.
  • the FH-Proxy50 records the rpc message (S14).
  • the FH-Proxy 50 may record the header and payload of the rpc message.
  • the O-RU60 transmits an rpc-reply message in which, for example, ru-id_A is set as the ru-id of the O-RU60 to the FH-Proxy50 (S15).
  • the FH-Proxy50 changes the Transport Layer address of the received rpc-reply message (S16). Specifically, the destination MAC address of the rpc-reply message is changed to the MAC address of O-DU70, and the source MAC address is changed to the MAC address of FH-Proxy50.
  • the parameters of the Yang module used when changing the Transport Layer address are the same as in step S12.
  • the FH-Proxy 50 forwards the rpc-reply message whose Transport Layer address has been changed to the O-DU 70 (S17).
  • the FH-Proxy50 records the rpc-reply message (S18).
  • the FH-Proxy 50 may record the header and payload of the rpc-reply message.
  • the FH-Proxy 50 uses ru-id_A, which is the O-RU60 information set in the rpc-reply message, as the information specified in the M-Plane. Can be recorded.
  • the O-DU 70 sets the edit-config intended to set the parameters in the rpc message, and sets the parameters in the O-RU 60. You may.
  • the FH-Proxy 50 also converts the Transport Layer address for the C-Plane, U-Plane, and S-Plane data, and records the information transmitted in each layer.
  • the FH-Proxy50 can record the message transferred in NETCONF by establishing an SSH connection with each of the O-RU60 and O-DU70 and setting the M-Plane.
  • the FH-Proxy50 can record the contents set in the header and payload of the message transferred in NETCONF.
  • the FH-Proxy50 can also record C-Plane, U-Plane, and S-Plane messages that are never transmitted over an SSH connection.
  • the FH-Proxy50 can record each message regarding M-Plane, C-Plane, U-Plane, and S-Plane.
  • the administrator or the like who manages the FH-Proxy 50 can use the recorded message for the analysis process.
  • the FH-Proxy 80 has a configuration in which a verification unit 81 is added to the communication device 10 of FIG.
  • the FH-Proxy 80 has a configuration in which a verification unit 81 that analyzes messages is added to the FH-Proxy 50 that records messages related to M-Plane, C-Plane, U-Plane, and S-Plane.
  • the functions or processes of the FH-Proxy 80 which are different from those of the communication device 10 and the FH-Proxy 50 corresponding to the communication device 10, will be mainly described.
  • the data recording unit 12 records, for example, Capability information regarding O-RU60, parameter values set by O-DU70 in O-RU60, and the like as data related to M-Plane. Further, the data recording unit 12 records the header and payload of each layer of each message regarding C-Plane, U-Plane, and S-Plane. Similar to the sequence of FIG. 10, the data recording unit 12 translates the Transport Layer address of each message regarding C-Plane, U-Plane, and S-Plane, and when transferring, the header of each message. And the payload may be recorded.
  • the verification unit 81 verifies the interconnection of O-RU60 and O-DU70 using various data recorded in the data recording unit 12.
  • the verification unit 81 may autonomously perform verification according to predetermined verification items.
  • the verification item may be to compare the information specified in the M-Plane with the parameters of the C-Plane, U-Plane, or S-Plane set based on the information.
  • the verification item may be to display the information transmitted / received by the M-plane in chronological order and compare whether or not the information is carried out in the order shown in FIG. The details of interconnection verification will be described below.
  • the data recording unit 12 records the Ethernet header of the message regarding C-Plane and U-Plane.
  • FIG. 12 shows an Ethernet header.
  • the Destination MAC Address and Source MAC Address included in the Ethernet header are the o-du-mac-address and o-ru-mac-address specified in the Transport flow of the o-ran-processing-element of M-Plane.
  • the VLAN ID included in the VLAN Tag included in the Ethernet header is the vlan-id specified in the Transport flow of the o-ran-processing-element of the M-Plane.
  • the CoS priority included in the VLAN Tag is u-plane-marking and c-plane-marking specified by M-Plane.
  • the verification unit 81 determines whether or not the information specified in the M-Plane matches the information set in the Ethernet header. When the verification unit 81 determines that they do not match, the verification unit 81 displays the analysis result that the information set in the Ethernet header and the information specified in the M-Plane are different values from the display connected to the FH-Proxy 80. May be output to the display unit such as.
  • the data recording unit 12 records the eCPRI Transport header included in the Ethernet payload of the message regarding C-Plane.
  • the ecpriVersion included in the eCPRI Transport header is the ecpriVersion included in the Capability information specified by O-RU60 in M-Plane.
  • ecpriRtcid / ecpriPcid is the eaxc-id specified in M-Plane.
  • the verification unit 81 determines whether or not the information specified in the M-Plane matches the information set in the eCPRI Transport header. When the verification unit 81 determines that they do not match, the verification unit 81 connects the analysis result that the information set in the eCPRI Transport header and the information specified in the M-Plane are different values to the FH-Proxy 80. It may be output to a display unit such as a display.
  • the data recording unit 12 records the Section Type 1 message in the Application layer of C-Plane.
  • Section Type 1 message is a message sent from O-DU70 to O-RU60 when the Capability information specified by O-RU60 in M-Plane indicates that it is a message supported by O-RU60. be.
  • the symInc included in the Section Type 1 message is set to 1 when it is indicated in the Capability information specified by the O-RU60 in the M-Plane that it is a parameter supported by the O-RU60.
  • the beamID is a Beamid included in the Capability information specified by O-RU60 in M-Plane.
  • udCompHdr is set based on the Compression method included in the Capability information specified by O-RU60 in M-Plane.
  • the verification unit 81 determines whether or not the information specified in the M-Plane matches the information set in the Section Type 1 message. Alternatively, the verification unit 81 may determine whether or not the information to be set based on the information specified in the M-Plane matches the information set in the Section Type 1 message. When the verification unit 81 determines that they do not match, the analysis result that the information set in the Section Type 1 message and the information specified in the M-Plane are different values is connected to the FH-Proxy 80. It may be output to a display unit such as a display.
  • the data recording unit 12 records a Section Type 3 message in the Application layer of C-Plane.
  • Section Type 3 message is a message sent from O-DU70 to O-RU60 when the Capability information specified by O-RU60 in M-Plane indicates that it is a message supported by O-RU60. be.
  • the Frame structure included in the Section Type 3 message is a value indicated in the Capability information specified by O-RU60 in M-Plane.
  • symInc is set to 1 when the Capability information specified by O-RU60 in M-Plane indicates that it is a parameter supported by O-RU60.
  • the beamID is a Beamid included in the Capability information specified by O-RU60 in M-Plane.
  • udCompHdr is set based on the Compression method included in the Capability information specified by O-RU60 in M-Plane.
  • the verification unit 81 determines whether or not the information specified in the M-Plane matches the information set in the Section Type 3 message. Alternatively, the verification unit 81 may determine whether or not the information to be set based on the information specified in the M-Plane matches the information set in the Section Type 3 message. When the verification unit 81 determines that they do not match, the analysis result that the information set in the Section Type 3 message and the information specified in the M-Plane are different values is connected to the FH-Proxy 80. It may be output to a display unit such as a display.
  • the data recording unit 12 records Section Type 1 and 3 messages in the U-Plane Application layer.
  • Section Type 3 message is a message sent from O-DU70 to O-RU60 when the Capability information specified by O-RU60 in M-Plane indicates that it is a message supported by O-RU60.
  • Section Type 1 and 3 symInc included in the message is set to 1 when it is indicated in the Capability information specified by O-RU60 in M-Plane that it is a parameter supported by O-RU60. Will be done.
  • udCompHdr is set based on the Compression method included in the Capability information specified by O-RU60 in M-Plane.
  • the verification unit 81 determines whether or not the information specified in the M-Plane matches the information set in the Section Type 1 and 3 messages. Alternatively, the verification unit 81 may determine whether or not the information to be set based on the information specified in the M-Plane matches the information set in the Section Type 1 and 3 messages. When the verification unit 81 determines that they do not match, the verification unit 81 connects the analysis result that the information set in the Section Type 1 and 3 messages and the information specified in the M-Plane are different values to the FH-Proxy 80. It may be output to a display unit such as a display.
  • the FH-Proxy 80 analyzes the message recorded by the data recording unit 12, and the information specified in the M-Plane matches the information set in the C-Plane and U-Plane. Judge whether or not. As a result, the FH-Proxy 80 can determine whether or not the information specified in the M-Plane is correctly set in the data transmitted from the O-RU 60 or the O-DU 70. Furthermore, the administrator of FH-Proxy80 analyzes the settings of O-RU60 or O-DU70, which is the source of the message, when it is determined that the information specified in M-Plane is not set correctly. By doing so, it is possible to analyze which device has a problem. Alternatively, the FH-Proxy 80 may autonomously analyze which device has a problem according to a predetermined scenario. Further, the message that can be verified by the verification unit 81 is not limited to the above-mentioned message.
  • the FH-Proxy 50 or FH-Proxy 80 is arranged between the O-RU 60 and the O-DU 70, and the FH-Proxy 50 or the FH-Proxy 80 is placed between the O-RU 60 and the O-DU 70.
  • the FH-Proxy 100 is arranged between the O-RU60 and the NMS90, and the FH-Proxy 100 acquires the message transmitted between the O-RU60 and the NMS90. You may.
  • the O-DU70 of FIG. 17 controls some parameters or functions of the O-RU60, and the NMS90 controls the remaining parameters or functions.
  • All or part of the communication unit, data recording unit, and verification unit of the FH-Proxy 80 at any node such as a network switch, bridge, router, and Fronthaul Multiplexer connected between the O-RU60 and the O-DU70 or NMS90. May be provided.
  • FIG. 18 is a block diagram showing a configuration example of the communication device 10, FH-Proxy50, FH-Proxy80, and FH-Proxy100 (hereinafter, referred to as communication device 10 and the like).
  • the communication device 10 and the like include a network interface 1201, a processor 1202, and a memory 1203.
  • Network interface 1201 is used to communicate with network nodes (e.g., eNB, MME, P-GW,).
  • the network interface 1201 may include, for example, a network interface card (NIC) compliant with the IEEE 802.3 series.
  • eNB represents evolved Node B
  • MME Mobility Management Entity
  • P-GW represents Packet Data Network Gateway. IEEE stands for Institute of Electrical and Electronics Engineers.
  • the processor 1202 reads the software (computer program) from the memory 1203 and executes it to perform the processing of the communication device 10 and the like described using the flowchart in the above-described embodiment.
  • Processor 1202 may be, for example, a microprocessor, MPU, or CPU.
  • Processor 1202 may include a plurality of processors.
  • Memory 1203 is composed of a combination of volatile memory and non-volatile memory. Memory 1203 may include storage located away from processor 1202. In this case, processor 1202 may access memory 1203 via an I / O (Input / Output) interface (not shown).
  • I / O Input / Output
  • the memory 1203 is used to store the software module group. By reading these software modules from the memory 1203 and executing the processor 1202, the processor 1202 can perform the processing of the communication device 10 and the like described in the above-described embodiment.
  • each of the processors included in the communication device 10 and the like in the above-described embodiment is one or a plurality of programs including a group of instructions for causing the computer to perform the algorithm described with reference to the drawings. To execute.
  • Non-temporary computer-readable media include various types of tangible storage media.
  • Examples of non-temporary computer-readable media include magnetic recording media (eg, flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (eg, magneto-optical disks), CD-ROMs (Read Only Memory), CD-Rs, It includes a CD-R / W and a semiconductor memory (for example, a mask ROM, a PROM (Programmable ROM), an EPROM (Erasable PROM), a flash ROM, and a RAM (RandomAccessMemory)).
  • a semiconductor memory for example, a mask ROM, a PROM (Programmable ROM), an EPROM (Erasable PROM), a flash ROM, and a RAM (RandomAccessMemory)
  • the program may also be supplied to the computer by various types of temporary computer readable medium.
  • temporary computer-readable media include electrical, optical, and electromagnetic waves.
  • the temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.
  • a first SSH (Secure Shell) connection is established between the communication terminal and the wireless device that performs wireless communication
  • a second SSH connection is established between the control device that performs baseband processing related to the signal used in the wireless communication.
  • the communication department to establish It includes a data recording unit that records the data of the management plane received from the wireless device via the first SSH connection or the data of the management plane received from the control device via the second SSH connection.
  • Communication device (Appendix 2) The communication unit The management received from the control device by changing the destination address of the first data of the management plane received from the wireless device to the first address indicating the control device and transmitting the first data to the control device.
  • the communication device according to Appendix 1, wherein the destination address of the second data of the plane is changed to the second address indicating the wireless device, and the second data is transmitted to the wireless device.
  • Appendix 3 The communication unit The source address of the first data transmitted to the control device is changed to a third address indicating the communication device, and the source address of the second data transmitted to the wireless device indicates the communication device.
  • the communication device according to Appendix 2 or 3 wherein the first data and the address set in the second data are MAC (Media Access Control) addresses.
  • the communication unit At least one of the control plane, the user plane, and the synchronization plane transmitted between the wireless device and the control device is acquired, and the destination address set in the acquired data is the management plane.
  • the communication device according to any one of Supplementary note 1 to 4, which is designated by using data.
  • the data recording unit Record at least one of the control plane, user plane, and synchronization plane data received from the radio or control. Any of Appendix 1 to 5, further comprising a verification unit for determining whether correct information is set in at least one of the control plane, the user plane, and the synchronization plane using the data of the management plane.
  • the communication device according to item 1.
  • (Appendix 7) Establish a first SSH (Secure Shell) connection between the communication terminal and the wireless device that performs wireless communication, A second SSH connection is established with the control device that performs baseband processing on the signal used in the wireless communication.
  • (Appendix 8) Establish a first SSH (Secure Shell) connection between the communication terminal and the wireless device that performs wireless communication, A second SSH connection is established with the control device that performs baseband processing on the signal used in the wireless communication.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

無線部とベースバンド部との間においてSSH（Secure Shell）コネクションが確立後に送信されるデータの取得を可能とする通信装置を提供すること。 本開示にかかる通信装置（１０）は、通信端末（４０）と無線通信を行う無線装置（２０）との間に第１のSSH（Secure Shell）コネクションを確立し、無線通信において用いられる信号に関するベースバンド処理を行う制御装置（３０）との間に第２のSSHコネクションを確立する通信部（１１）と、無線装置（２０）から第１のSSHコネクションを介して受信したマネジメントプレーンのデータまたは制御装置（３０）から第２のSSHコネクションを介して受信したマネジメントプレーンのデータを記録するデータ記録部（１２）と、を備える。

Description

通信装置、データ記録方法、及び非一時的なコンピュータ可読媒体
　本開示は、通信装置、データ記録方法、及びプログラムに関する。
　近年、基地局のベースバンド部と無線部とを切り離し、ベースバンド部と無線部とをフロントホールを介して接続する無線アクセスネットワークが用いられている。O-RAN（Open-Radio Access Network）アライアンスにおいて規定されたO-RANフロントホール仕様は、無線部に相当するO-RU（Radio Unit）とベースバンド部に相当するO-DU（Distributed Unit）との間のフロントホールの仕様を規定している。O-RANフロントホール仕様は、O-DUのベンダと異なるベンダのO-RUとの接続を容易にし、無線アクセスネットワークのマルチベンダ化を実現することを一つの目的としている。
　非特許文献１には、O-DUとO-RUとの間の相互接続性を検証するための手順、解析方法等が開示されている。非特許文献１には、O-DUとO-RUとの間にFH（Fronthaul） Protocolアナライザを接続し、FH Protocolアナライザを用いてO-DUとO-RUとの間において送信されるデータを解析することが開示されている。
ORAN-WG4.IOT.0-v01.00 O-RAN Fronthaul Working Group Fronthaul Interoperability Test Specification (IOT)
　しかし、非特許文献１に開示されているFH Protocolアナライザは、O-DUとO-RUとの間のSSH（Secure Shell）コネクションが確立する前に取得することができるデータしか解析することができない。つまり、O-DUとO-RUとの間においてSSHコネクションが確立された後は、FH Protocolアナライザは、SSHを介して送信される情報を取得することができない。そのため、FH Protocolアナライザは、SSHコネクション上でO-DUとO-RUとの間において送信されるデータを解析することができないという問題がある。
　本開示の目的は、無線部とベースバンド部との間においてSSH（Secure Shell）コネクションが確立後にSSHコネクションにおいて送信されるデータの取得を可能とする通信装置、データ記録方法、及びプログラムを提供することにある。
　本開示の第１の態様にかかる通信装置は、通信端末と無線通信を行う無線装置との間に第１のSSH（Secure Shell）コネクションを確立し、前記無線通信において用いられる信号に関するベースバンド処理を行う制御装置との間に第２のSSHコネクションを確立する通信部と、前記無線装置から前記第１のSSHコネクションを介して受信したマネジメントプレーンのデータまたは前記制御装置から前記第２のSSHコネクションを介して受信したマネジメントプレーンのデータを記録するデータ記録部と、を備える。
　本開示の第２の態様にかかるデータ記録方法は、通信端末と無線通信を行う無線装置との間に第１のSSH（Secure Shell）コネクションを確立し、前記無線通信において用いられる信号に関するベースバンド処理を行う制御装置との間に第２のSSHコネクションを確立し、前記無線装置から前記第１のSSHコネクションを介して受信したマネジメントプレーンのデータまたは前記制御装置から前記第２のSSHコネクションを介して受信した前記マネジメントプレーンのデータを記録する。
　本開示の第３の態様にかかるプログラムは、通信端末と無線通信を行う無線装置との間に第１のSSH（Secure Shell）コネクションを確立し、前記無線通信において用いられる信号に関するベースバンド処理を行う制御装置との間に第２のSSHコネクションを確立し、前記無線装置から前記第１のSSHコネクションを介して受信したマネジメントプレーンのデータまたは前記制御装置から前記第２のSSHコネクションを介して受信した前記マネジメントプレーンのデータを記録することをコンピュータに実行させる。
　本開示により、無線部とベースバンド部との間においてSSH（Secure Shell）コネクションが確立後に送信されるデータの取得を可能とする通信装置、データ記録方法、及びプログラムを提供することができる。
実施の形態１にかかる通信装置の構成図である。 実施の形態２にかかる通信システムの構成図である。 実施の形態２にかかるM-Planeのプロトコルスタックを示す図である。 実施の形態２にかかるC/U-Planeのプロトコルスタックを示す図である。 実施の形態２にかかるS-Planeのプロトコルスタックを示す図である。 実施の形態２にかかるM-Planeに関するStar-upシーケンスを示す図である。 実施の形態２にかかるSSHコネクションを示す図である。 実施の形態２にかかるYangモジュールを示す図である。 実施の形態２にかかるFH-Proxyと、O-RU及びO-DUとの間に定義されたflowを示す図である。 実施の形態２にかかるType Bに分類される処理の流れを示す図である。 実施の形態３にかかるFH-Proxyの構成図である。 実施の形態３にかかるEthernetヘッダを示す図である。 実施の形態３にかかるeCPRI Transportヘッダを示す図である。 実施の形態３にかかるC-PlaneのSection Type 1メッセージを示す図である。 実施の形態３にかかるC-PlaneのSection Type 3メッセージを示す図である。 実施の形態３にかかるU-PlaneのSection Type 1及び3メッセージを示す図である。 実施の形態２及び３の通信システムの変形例を示す図である。 それぞれの実施の形態にかかる通信装置及びFH-Proxyの構成図である。
　（実施の形態１）
　以下、図面を参照して本開示の実施の形態について説明する。はじめに、図１を用いて実施の形態１にかかる通信装置１０の構成例について説明する。通信装置１０は、プログラムを実行することによって動作するコンピュータ装置であってもよい。
　通信装置１０は、通信部１１及びデータ記録部１２を有している。通信部１１及びデータ記録部１２は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。
　通信部１１は、通信端末４０と無線通信を行う無線装置２０との間に第１のSSHコネクションを確立し、無線装置２０において用いられる信号に関するベースバンド処理を行う制御装置３０との間に第２のSSHコネクションを確立する。通信端末４０は、例えば、スマートフォン端末、IoT（Internet of Things）端末、MTC（Machine Type Communication）装置等であってもよい。
　無線装置２０は、例えばO-RANアライアンスにおいて定められているO-RUエンティティ（以下、O-RU、とする）であってもよい。制御装置３０は、例えば、O-RANアライアンスにおいて定められているO-DUエンティティ（以下、O-DU、とする）であってもよい。エンティティは、ノードもしくはノード装置と称されてもよい。
　通信装置１０には、例えば、無線装置２０が生成した公開鍵Ａ及び秘密鍵Ａのうち、公開鍵Ａが予めインストールされているとする。さらに、通信装置１０は、公開鍵Ｂ及び秘密鍵Ｂを生成し、公開鍵Ｂが、制御装置３０に予めインストールされているとする。通信部１１は、無線装置２０と、公開鍵Ａを用いた認証を実施することによって、無線装置２０との間に第１のSSHコネクションを確立する。また、通信部１１は、制御装置３０と、公開鍵Ｂを用いた認証を実施することによって、制御装置３０との間に第２のSSHコネクションを確立する。SSHコネクションの確立は、公開鍵を用いた方法に限定されず、他の方法によって行われてもよい。
　データ記録部１２は、無線装置２０から第１のSSHコネクションを介して受信したマネジメントプレーンのデータを記録する。さらに、データ記録部１２は、制御装置３０から第２のSSHコネクションを介して受信したマネジメントプレーンのデータを記録する。
　通信装置１０は、第１のSSHコネクション及び第２のSSHコネクションをそれぞれ終端する。そのため、データ記録部１２は、第１のSSHコネクションまたは第２のSSHコネクションを介して受信した暗号化されたデータを復号することができる。つまり、データ記録部１２は、データのそれぞれのレイヤのヘッダ及びペイロードの解析が可能な形式のデータを保持する。
　マネジメントプレーンは、例えば、制御装置３０もしくはNMS（Network Management System）が無線装置２０を保守もしくは監視するために用いられるデータもしくはメッセージを扱う。マネジメントプレーンのデータとは、マネジメントプレーンにおいて送受信されるデータである。
　以上説明したように、実施の形態１にかかる通信装置１０は、無線装置２０及び制御装置３０のそれぞれとSSHコネクションを確立することができる。そのため、一般的には、無線装置２０と制御装置３０との間においてSSHコネクションを介して送信されるマネジメントプレーンのデータを、ヘッダ及びペイロードの解析を可能とする形式にて保持することができる。その結果、通信装置１０は、無線装置２０と制御装置３０との間においてSSHコネクションが確立後に送信されるデータを取得し、取得したデータを解析することができる。
　（実施の形態２）
　続いて、図２を用いて実施の形態２にかかる通信システムの構成例について説明する。図２の通信システムは、主に、O-RANアライアンスにおいて規定されたシステム構成を示している。図２の通信システムは、FH（Fronthaul）-Proxyエンティティ（以下、FH-Proxy、とする）５０、O-RU６０、及びO-DU７０を有している。
　FH-Proxy５０は、図１の通信装置１０に相当する。O-RU６０は、図１の無線装置２０に相当する。O-DU７０は、図１の制御装置３０に相当する。
　FH-Proxy５０とO-RU６０との間には、M（Management）-Plane、C（Control）-Plane、U（User）-Plane、及びS（Synchronization）-Planeが設定されている。さらに、FH-Proxy５０とO-DU７０との間にもM-Plane、C-Plane、U-Plane、及びS-Planeが設定されている。FH-Proxy５０は、O-RU６０に対しては、O-DUとして疑似的に振る舞い、O-DU７０に対しては、O-RUとして疑似的に振る舞う。
　M-Planeは、装置を監視もしくは保守するために用いる監視信号を転送するためのプロトコルである。具体的には、図３に、M-Planeのプロトコルスタックが示されている。M-Planeでは、NETCONF（NETwork CONFigutation protocol）において用いられる信号を、Ethernet（登録商標）/IP/TCP（Transmission Control Protocol）/SSHを用いて伝送するプロトコルスタックがサポートされている。
　C-Planeは、制御信号を転送するためのプロトコルである。また、U-Planeは、ユーザデータを転送するためのプロトコルである。具体的には、図４に、C-Plane及びU-Planeのプロトコルスタックが示されている。C-Plane及びU-Planeでは、eCPRI（ehnanced Common Public Radio Interface）もしくはRoE（Radio over Ethernet）において用いられる信号を、Ethernet/IP/UDP（User Datagram Protocol）を用いて伝送するプロトコルスタックがサポートされている。もしくは、C-Plane及びU-Planeでは、eCPRIもしくはRoEにおいて用いられる信号を、直接Ethernetを用いて伝送するプロトコルスタックがサポートされていてもよい。
　S-Planeは、装置間の同期を実現するためのプロトコルである。具体的には、図５に、S-Planeのプロトコルスタックが示されている。S-Planeでは、PTP（Precision Time Protocol）及びSyncEにおいて用いられる信号をEthernetを用いて伝送するプロトコルスタックがサポートされている。
　続いて、図６を用いてM-Planeに関するStart-upシーケンスについて説明する。図６は、例えば、O-DU７０における管理対象となるO-RU６０が起動してから、O-DU７０によるO-RU６０の管理が可能となるまでの手順が示されている。管理は、監視と言い換えられてもよい。また、NETCONFにおいては、O-RU６０を管理するネットワーク機器であるO-DU７０が、NETCONFクライアントに該当し、管理対象となるO-RU６０がNETCONFサーバに該当する。
　図６においては、O-DU ７０に該当するNETCONFクライアントおよびO-RU ６０に該当するNETCONFサーバとの間においてそれぞれの処理が実行されることが示されている。ここで、実施の形態２において用いられる通信システムは、O-DU ７０とO-RU ６０との間にFH-Proxy ５０が配置される構成である。そのため、図６は、NETCONFクライアント、FH-Proxy ５０、及びNETCONFサーバとの間において実行されるStart-up処理を示す。
　はじめに、FH-Proxy５０、O-RU６０、及びO-DU７０は、図６に示されるType Aに分類される、Transport Layer InitializationからSSH Secure Connection Establishedまでの処理を実行する。Type Aに分類される処理は、O-RU６０とFH-Proxy５０との間の処理と、O-DU７０とFH-Proxy５０との間の処理とが独立して実施される処理である。Type Aに分類される処理においては、FH-Proxy ５０は、NETCONFサーバであるO-RU ６０と通信する際には、NETCONFクライアントとして動作する。さらに、FH-Proxy ５０は、NETCONFクライアントであるO-DU ７０と通信する際には、NETCONFサーバとして動作する。Type Aに分類される処理を実行した結果、図７に示されるように、FH-Proxy５０とO-RU６０との間、ならびに、FH-Proxy５０とO-DU７０との間に、それぞれSSHコネクションが確立される。
　また、FH-Proxy５０、O-RU６０、及びO-DU７０は、Type Aに分類される処理を実行することによって、Transport Layerの設定も行う。Transport Layerの設定は、例えば、Transport Layerアドレスである、IPアドレスもしくはEthernetアドレスを、それぞれの装置に設定することであってもよい。FH-Proxy５０は、O-DU７０と通信を行うためのTransport Layerアドレスには、O-RU６０と通信を行うためのTransport Layerアドレスとは異なるTransport Layerアドレスを設定する。
　Type Aに分類される処理が実行されることによって、Transport Layerの設定及びSSHコネクションの確立は、O-RU６０とFH-Proxy５０との間のリンク、及び、O-DU７０とFH-Proxy５０との間のリンクにおいて個別に実行される。
　次に、FH-Proxy５０、O-RU６０、及びO-DU７０は、図６に示されるType Bに分類される、NETCONF Capability discoveryからConfiguration the O-RU operational parametersまでの処理を実行する。Type Bに分類される処理は、FH-Proxy５０を介して、NETCONFサーバであるO-RU６０とNETCONFクライアントであるO-DU７０との間において実行される処理である。
　図６に示されるStart-upシーケンスのそれぞれの処理は、NETCONFに規定されるメッセージを用いて実行される。メッセージに設定されるパラメータのセットは、図８に示すYangモジュールにて規定されている。図８において、Aと記載されているパラメータが、Type Aの処理において用いられるパラメータであり、そのほかのパラメータは、Type Bの処理において用いられる。また、図８において、O-RU Capabilityと記載されているパラメータは、O-RU６０がサポートするCapability情報を示している。NETCONFに規定されるメッセージとして、例えば、rpcメッセージ、rpc-replyメッセージ、もしくはnotificationメッセージが用いられる。O-DU７０及びO-RU６０は、これらのメッセージを用いてパラメータの設定（edit-config）もしくはパラメータの取得（get-config）等を実行する。
　例えば、O-RU ６０及びFH-Proxy ５０は、Yangモジュールのo-ran-processing elementのTransport flowにおいて指定されたMACアドレスを設定する。これによって、O-RU６０とFH-Proxy５０との間に定義されるflowの両端のアドレスが定められる。それぞれのアドレスは、O-RU ６０とFH-Proxy ５０との間において送信されるデータのSource address及びDestination Addressとなりうる。さらに、O-DU７０及びFH-Proxy５０も同様に、Yangモジュールのo-ran-processing elementのTransport flowにおいて指定されたMACアドレスを設定する。これによって、O-RU６０とFH-Proxy５０との間に定義されるflowの両端のアドレスが定められる。それぞれのアドレスは、O-DU ７０とFH-Proxy ５０との間において送信されるデータのSource address及びDestination Addressとなりうる。
　図９は、o-ran-processing-elementにおいて指定されたアドレス情報を用いて定義されたflowを示している。図９は、FH-Proxy５０が、O-RU６１、O-RU６２、及びO-RU６３と、O-DU７１、O-DU７２、及びO-DU７３との間に配置されていることを示している。FH-Proxy５０に接続されるO-DUおよびO-RUの数は一つずつではなく、図９の通りそれぞれ複数であり、同数である必要はない。
　FH-Proxy５０は、O-DU７１のAddress-1及びFH-Proxy５０のアドレス-1Aをflow1と定義し、O-DU７１と通信を行う。flowは、Transport flowと称されてもよい。同様に、FH-Proxy５０は、O-DU７２のAddress-2及びFH-Proxy５０のアドレス-2Aをflow2と定義し、O-DU７２と通信を行う。FH-Proxy５０は、O-DU７３のAddress-3及びFH-Proxy５０のアドレス-3Aをflow3と定義し、O-DU７３と通信を行う。FH-Proxy５０は、O-RU６１のAddress-4及びFH-Proxy５０のアドレス-4Aをflow4と定義し、O-RU６１と通信を行う。FH-Proxy５０は、O-RU６２のAddress-5及びFH-Proxy５０のアドレス-5Aをflow5と定義し、O-RU６２と通信を行う。FH-Proxy５０は、O-RU６３のAddress-6及びFH-Proxy５０のアドレス-6Aをflow6と定義し、O-RU６３と通信を行う。
　FH-Proxy５０のO-DU側接続数とO-RU側接続数は複数であるので、FH-Proxy５０における設定を実施することで、O-DU及びO-RUを物理的に抜き差しする必要なく、FH-Proxy５０に接続されている任意のO-DUと任意のO-RUとの相互接続検証を実施することができる。
　例えば、FH-Proxy５０は、O-DU７１とO-RU６１との相互接続検証を行う場合、Address-1AとAddress-4Aとを用いて検証を行う。言い換えると、FH-Proxy５０は、O-DU７１とO-RU６１の相互接続検証を行う場合、flow1とflow4とを用いて検証を行う。同様に、FH-Proxy５０は、O-DU７２とO-RU６３の相互接続検証を行う場合、Address-2AとAddress-6Aとを用いて検証を行う。
　FH-Proxy５０は、Type Bの処理を実行する場合、図９に示すようにTransport Layerアドレスを終端し変換するが、上位レイヤであるNETCONF layerを透過させる。FH-Proxy５０は、NETCONF layerにおいて伝送される情報を記録する。言い換えると、FH-Proxy５０は、NETCONF layerにおいて伝送される情報をログとして記録し、NETCONF layerにおいて伝送される情報を可視化する。また、FH-Proxy５０は、Type Aの処理を実行する場合も、NETCONF layerにおいて伝送される情報をログとして記録し、NETCONF layerにおいて伝送される情報を可視化する。
　ここで、図１０を用いてType Bに分類される処理の一例として、Retrieval of O-RU Informationに関する処理について説明する。Retrieval of O-RU Informationに関する処理は、O-DU７０がO-RU６０に関するパラメータを取得するために行われる処理である。はじめに、O-DU７０は、パラメータの取得を意図するget-config、及び、取得対象のパラメータを示すru-idを設定したrpcメッセージをFH-Proxy５０へ送信する（Ｓ１１）。
　次に、FH-Proxy５０は、受信したrpcメッセージのTransport Layerアドレスを変更する（Ｓ１２）。具体的には、rpcメッセージの宛先MACアドレスをO-RU６０のMACアドレスへ変更し、送信元MACアドレスをFH-Proxy５０のMACアドレスへ変更する。FH-Proxy５０は、Transport Layerアドレスを変更する場合、Type Aに分類される処理において用いられる、ietf-interface、o-ran-interface、o-ran-processing-elementを変更する。次に、FH-Proxy ５０は、Transport Layerアドレスを変更したrpcメッセージをO-RU６０へ転送する（Ｓ１３）。この時、FH-Proxy５０は、rpcメッセージのNETCONF layerの情報を透過する。
　次に、FH-Proxy５０は、rpcメッセージを記録する（Ｓ１４）。例えば、FH-Proxy５０は、rpcメッセージのヘッダ及びペイロードを記録してもよい。
　次に、O-RU６０は、O-RU６０のru-idとして、例えば、ru-id_Aを設定したrpc-replyメッセージをFH-Proxy５０へ送信する（Ｓ１５）。
　次に、FH-Proxy５０は、受信したrpc-replyメッセージのTransport Layerアドレスを変更する（Ｓ１６）。具体的には、rpc-replyメッセージの宛先MACアドレスをO-DU７０のMACアドレスへ変更し、送信元MACアドレスをFH-Proxy５０のMACアドレスへ変更する。Transport Layerアドレスを変更する際に用いられるYangモジュールのパラメータは、ステップＳ１２と同様である。次に、FH-Proxy ５０は、Transport Layerアドレスを変更したrpc-replyメッセージをO-DU７０へ転送する（Ｓ１７）。
　次に、FH-Proxy５０は、rpc-replyメッセージを記録する（Ｓ１８）。例えば、FH-Proxy５０は、rpc-replyメッセージのヘッダ及びペイロードを記録してもよい。FH-Proxy ５０は、rpc-replyメッセージのヘッダ及びペイロードを記録することによって、M-Planeにおいて指定された情報として、rpc-replyメッセージに設定されているO-RU６０の情報であるru-id_Aを記録することができる。
　図１０においては、Retrieval of O-RU Informationについて説明したが、その他の処理において、O-DU７０は、パラメータの設定を意図するedit-configをrpcメッセージに設定して、O-RU６０にパラメータを設定してもよい。
　図１０においては、M-Planeにおいて送信されるデータの流れについて説明したが、C-Plane、U-Plane、及びS-Planeのデータについても同様である。つまり、FH-Proxy ５０は、C-Plane、U-Plane、及びS-Planeのデータについても、Transport Layerのアドレスを変換し、各レイヤにおいて送信される情報を記録する。
　以上説明したように、FH-Proxy５０は、O-RU６０及びO-DU７０のそれぞれと、SSHコネクションを確立してM-Planeを設定することによって、NETCONFにおいて転送されるメッセージを記録することができる。言い換えると、FH-Proxy５０は、NETCONFにおいて転送されるメッセージのヘッダ及びペイロードに設定されている内容を記録することができる。さらに、FH-Proxy５０は、SSHコネクションを介して送信されることのないC-Plane、U-Plane、及びS-Planeのメッセージも記録することができる。
　このようにして、FH-Proxy５０は、M-Plane、C-Plane、U-Plane、及びS-Planeに関するそれぞれのメッセージを記録することができる。その結果、FH-Proxy５０を管理する管理者等は、記録されたメッセージを解析処理に用いることができる。
　（実施の形態３）
　続いて、図１１を用いて、実施の形態３にかかるFH-Proxy８０の構成例について説明する。FH-Proxy８０は、図１の通信装置１０に、検証部８１が追加された構成である。FH-Proxy８０は、M-Plane、C-Plane、U-Plane、及びS-Planeに関するそれぞれのメッセージを記録するFH-Proxy５０に、メッセージの解析処理を行う検証部８１が追加された構成である。以下においては、FH-Proxy８０について、通信装置１０及び通信装置１０に相当するFH-Proxy５０と異なる機能もしくは処理について主に説明する。
　データ記録部１２は、M-Planeに関するデータとして、例えば、O-RU６０に関するCapability情報、O-DU７０がO-RU６０に設定するパラメータ値等を記録している。さらに、データ記録部１２は、C-Plane、U-Plane、及びS-Planeに関するそれぞれのメッセージのそれぞれのレイヤのヘッダ及びペイロードを記録する。データ記録部１２は、図１０のシーケンスと同様に、C-Plane、U-Plane、及びS-Planeに関するそれぞれのメッセージのTransport Layerのアドレスを変換し、転送する際にそれぞれのメッセージのそれぞれのヘッダ及びペイロードを記録してもよい。
　検証部８１は、データ記録部１２において記録された各種データを用いて、O-RU６０及びO-DU７０の相互接続検証を行う。検証部８１は、予め定められた検証項目に従って、自律的に検証を行ってもよい。例えば、検証項目は、M-Planeにおいて指定された情報と、その情報に基づいて設定されたC-Plane、U-Plane、もしくはS-Planeのパラメータとを比較することであってもよい。または、検証項目は、M-planeで送受信された情報を時系列で表示し、図６の順序の通りに実施されているかを比較することであってもよい。以下に、相互接続検証の詳細について説明する。
　データ記録部１２は、C-Plane及びU-Planeに関するメッセージのEthernetヘッダを記録する。図１２は、Ethernetヘッダを示している。Ethernetヘッダに含まれるDestination MAC Address及びSource MAC Addressは、M-Planeのo-ran-processing-elementのTransport flowにおいて指定されたo-du-mac-address及びo-ru-mac-addressである。さらに、Ethernetヘッダに含まれるVLAN Tagに含まれるVLAN IDは、M-Planeのo-ran-processing-elementのTransport flowにおいて指定されたvlan-idである。さらに、VLAN Tag内に含まれるCoS priorityは、M-Planeで指定されるu-plane-marking及びc-plane-markingである。
　検証部８１は、M-Planeにおいて指定された情報と、Ethernetヘッダに設定された情報とが一致するか否かを判定する。検証部８１は、一致しないと判定した場合、Ethernetヘッダに設定された情報と、M-Planeにおいて指定された情報とが異なる値である、という分析結果を、FH-Proxy８０に接続されているディスプレイ等の表示部へ出力してもよい。
　続いて、図１３を用いて、eCPRI Transportヘッダについて説明する。データ記録部１２は、C-Planeに関するメッセージのEthernetペイロードに含まれるeCPRI Transportヘッダを記録する。
　eCPRI Transportヘッダに含まれるecpriVersionは、M-PlaneにおいてO-RU６０が指定するCapability情報に含まれるecpriVersionである。さらに、ecpriRtcid/ecpriPcidは、M-Planeにおいて指定されたeaxc-idである。
　検証部８１は、M-Planeにおいて指定された情報と、eCPRI Transportヘッダに設定された情報とが一致するか否かを判定する。検証部８１は、一致しないと判定した場合、eCPRI Transportヘッダに設定された情報と、M-Planeにおいて指定された情報とが異なる値である、という分析結果を、FH-Proxy８０に接続されているディスプレイ等の表示部へ出力してもよい。
　続いて、図１４を用いて、C-PlaneのApplication layerにおけるSection Type 1に規定されるメッセージについて説明する。データ記録部１２は、C-PlaneのApplication layerにおけるSection Type 1メッセージを記録する。
　Section Type 1メッセージは、M-PlaneにおいてO-RU６０が指定するCapability情報においてO-RU６０がサポートするメッセージであることが示されている場合に、O-DU７０からO-RU６０へ送信されるメッセージである。Section Type 1メッセージに含まれるsymIncは、M-PlaneにおいてO-RU６０が指定するCapability情報においてO-RU６０がサポートするパラメータであることが示されている場合に、１が設定される。beamIDは、M-PlaneにおいてO-RU６０が指定するCapability情報に含まれるBeam idである。udCompHdrは、M-PlaneにおいてO-RU６０が指定するCapability情報に含まれるCompression methodに基づいて設定される。
　検証部８１は、M-Planeにおいて指定された情報と、Section Type 1メッセージに設定された情報とが一致するか否かを判定する。もしくは、検証部８１は、M-Planeにおいて指定された情報に基づいて設定されるべき情報と、Section Type 1メッセージに設定された情報とが一致するか否かを判定してもよい。検証部８１は、一致しないと判定した場合、Section Type 1メッセージに設定された情報と、M-Planeにおいて指定された情報とが異なる値である、という分析結果を、FH-Proxy８０に接続されているディスプレイ等の表示部へ出力してもよい。
　続いて、図１５を用いて、C-PlaneのApplication layerにおけるSection Type 3に規定されるメッセージについて説明する。データ記録部１２は、C-PlaneのApplication layerにおけるSection Type 3メッセージを記録する。
　Section Type 3メッセージは、M-PlaneにおいてO-RU６０が指定するCapability情報においてO-RU６０がサポートするメッセージであることが示されている場合に、O-DU７０からO-RU６０へ送信されるメッセージである。Section Type 3メッセージに含まれるFrame structureは、M-PlaneにおいてO-RU６０が指定するCapability情報に示されている値である。symIncは、M-PlaneにおいてO-RU６０が指定するCapability情報においてO-RU６０がサポートするパラメータであることが示されている場合に、１が設定される。beamIDは、M-PlaneにおいてO-RU６０が指定するCapability情報に含まれるBeam idである。udCompHdrは、M-PlaneにおいてO-RU６０が指定するCapability情報に含まれるCompression methodに基づいて設定される。
　検証部８１は、M-Planeにおいて指定された情報と、Section Type 3メッセージに設定された情報とが一致するか否かを判定する。もしくは、検証部８１は、M-Planeにおいて指定された情報に基づいて設定されるべき情報と、Section Type 3メッセージに設定された情報とが一致するか否かを判定してもよい。検証部８１は、一致しないと判定した場合、Section Type 3メッセージに設定された情報と、M-Planeにおいて指定された情報とが異なる値である、という分析結果を、FH-Proxy８０に接続されているディスプレイ等の表示部へ出力してもよい。
　続いて、図１６を用いて、U-PlaneのApplication layerにおけるSection Type 1及び3に規定されるメッセージについて説明する。データ記録部１２は、U-PlaneのApplication layerにおけるSection Type 1及び3メッセージを記録する。
　Section Type 3メッセージは、M-PlaneにおいてO-RU６０が指定するCapability情報においてO-RU６０がサポートするメッセージであることが示されている場合に、O-DU７０からO-RU６０へ送信されるメッセージである。Section Type 1及び3メッセージに含まれるsymIncは、M-PlaneにおいてM-PlaneにおいてO-RU６０が指定するCapability情報においてO-RU６０がサポートするパラメータであることが示されている場合に、１が設定される。udCompHdrは、M-PlaneにおいてO-RU６０が指定するCapability情報に含まれるCompression methodに基づいて設定される。
　検証部８１は、M-Planeにおいて指定された情報と、Section Type 1及び3メッセージに設定された情報とが一致するか否かを判定する。もしくは、検証部８１は、M-Planeにおいて指定された情報に基づいて設定されるべき情報と、Section Type 1及び3メッセージに設定された情報とが一致するか否かを判定してもよい。検証部８１は、一致しないと判定した場合、Section Type 1及び3メッセージに設定された情報と、M-Planeにおいて指定された情報とが異なる値である、という分析結果を、FH-Proxy８０に接続されているディスプレイ等の表示部へ出力してもよい。
　以上説明したように、FH-Proxy８０は、データ記録部１２が記録したメッセージを解析し、M-Planeにおいて指定された情報と、C-Plane及びU-Planeにおいて設定された情報とが一致しているか否かを判定する。これにより、FH-Proxy８０は、O-RU６０もしくはO-DU７０から送信されるデータに、M-Planeにおいて指定された情報が正しく設定されているか否かを判定することができる。さらに、FH-Proxy８０の管理者等は、M-Planeにおいて指定された情報が正しく設定されていないと判定された場合に、メッセージの送信元のO-RU６０もしくはO-DU７０等の設定内容を解析することによって、どの装置に問題があるかを分析することができる。または、FH-Proxy８０が、予め定められたシナリオに従い、自律的にどの装置に問題があるかを分析してもよい。また、検証部８１が検証可能なメッセージは上述のメッセージには限られない。
　（実施の形態２及び３の変形例）
　実施の形態２においては、O-RU６０とO-DU７０との間にFH-Proxy５０もしくはFH-Proxy８０が配置され、FH-Proxy ５０もしくはFH-Proxy ８０がO-RU６０とO-DU７０との間において伝送されるメッセージを取得することを説明した。これに対して、図１７に示されるように、O-RU６０とNMS９０との間にFH-Proxy１００が配置され、FH-Proxy １００がO-RU６０とNMS９０との間において伝送されるメッセージを取得してもよい。図１７のO-DU７０が、O-RU６０の一部のパラメータもしくは機能を制御し、NMS９０が、残りのパラメータもしくは機能を制御する。O-RU６０とO-DU７０またはNMS９０との間に接続されるネットワークスイッチ、ブリッジ、ルーター、およびFronthaul MultiplexerなどいずれかのノードにおいてFH-Proxy８０における通信部、データ記録部、検証部の全てもしくは一部を具備してもよい。
　図１８は、通信装置１０、FH-Proxy５０、FH-Proxy８０、及びFH-Proxy１００（以下、通信装置１０等と称する）の構成例を示すブロック図である。図１８を参照すると、通信装置１０等は、ネットワークインタフェース１２０１、プロセッサ１２０２、及びメモリ１２０３を含む。ネットワークインタフェース１２０１は、ネットワークノード（e.g., eNB、MME、P-GW、）と通信するために使用される。ネットワークインタフェース１２０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。ここで、eNBはevolved Node B、MMEはMobility Management Entity、P-GWはPacket Data Network Gatewayを表す。IEEEは、Institute of Electrical and Electronics Engineersを表す。
　プロセッサ１２０２は、メモリ１２０３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態においてフローチャートを用いて説明された通信装置１０等の処理を行う。プロセッサ１２０２は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ１２０２は、複数のプロセッサを含んでもよい。
　メモリ１２０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１２０３は、プロセッサ１２０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１２０２は、図示されていないI/O（Input/Output）インタフェースを介してメモリ１２０３にアクセスしてもよい。
　図１８の例では、メモリ１２０３は、ソフトウェアモジュール群を格納するために使用される。プロセッサ１２０２は、これらのソフトウェアモジュール群をメモリ１２０３から読み出して実行することで、上述の実施形態において説明された通信装置１０等の処理を行うことができる。
　図１８を用いて説明したように、上述の実施形態における通信装置１０等が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。
　上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ－ＲＯＭ（Read Only Memory）、ＣＤ－Ｒ、ＣＤ－Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
　以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
　なお、本開示は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。
　この出願は、２０２０年３月１１日に出願された日本出願特願２０２０－０４２４６７を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
　（付記１）
　通信端末と無線通信を行う無線装置との間に第１のSSH（Secure Shell）コネクションを確立し、前記無線通信において用いられる信号に関するベースバンド処理を行う制御装置との間に第２のSSHコネクションを確立する通信部と、
　前記無線装置から前記第１のSSHコネクションを介して受信したマネジメントプレーンのデータまたは前記制御装置から前記第２のSSHコネクションを介して受信した前記マネジメントプレーンのデータを記録するデータ記録部と、を備える通信装置。
　（付記２）
　前記通信部は、
　前記無線装置から受信したマネジメントプレーンの第１のデータの宛先アドレスを前記制御装置を示す第１のアドレスへ変更して前記第１のデータを前記制御装置へ送信し、前記制御装置から受信したマネジメントプレーンの第２のデータの宛先アドレスを前記無線装置を示す第２のアドレスへ変更して前記第２のデータを前記無線装置へ送信する、付記１に記載の通信装置。
　（付記３）
　前記通信部は、
　前記制御装置へ送信する前記第１のデータの送信元アドレスを前記通信装置を示す第３のアドレスへ変更し、前記無線装置へ送信する前記第２のデータの送信元アドレスを前記通信装置を示す第４のアドレスへ変更する、付記２に記載の通信装置。
　（付記４）
　前記第１のデータ及び前記第２のデータに設定されるアドレスは、MAC（Media Access Control）アドレスである、付記２又は３に記載の通信装置。
　（付記５）
　前記通信部は、
　前記無線装置と前記制御装置との間において送信されるコントロールプレーン、ユーザプレーン、及び同期プレーンのうち少なくとも一つのデータを取得し、取得された前記データに設定される宛先アドレスは、前記マネジメントプレーンのデータを用いて指定される、付記１乃至４のいずれか１項に記載の通信装置。
　（付記６）
　前記データ記録部は、
　前記無線装置または前記制御装置から受信したコントロールプレーン、ユーザプレーン、及び同期プレーンのうち少なくとも一つのデータを記録し、
　前記マネジメントプレーンのデータを用いて、前記コントロールプレーン、前記ユーザプレーン、及び前記同期プレーンのうち少なくとも一つのデータに正しい情報が設定されているかを判定する検証部をさらに備える、付記１乃至５のいずれか１項に記載の通信装置。
　（付記７）
　通信端末と無線通信を行う無線装置との間に第１のSSH（Secure Shell）コネクションを確立し、
　前記無線通信において用いられる信号に関するベースバンド処理を行う制御装置との間に第２のSSHコネクションを確立し、
　前記無線装置から前記第１のSSHコネクションを介して受信したマネジメントプレーンのデータまたは前記制御装置から前記第２のSSHコネクションを介して受信した前記マネジメントプレーンのデータを記録する、データ記録方法。
　（付記８）
　通信端末と無線通信を行う無線装置との間に第１のSSH（Secure Shell）コネクションを確立し、
　前記無線通信において用いられる信号に関するベースバンド処理を行う制御装置との間に第２のSSHコネクションを確立し、
　前記無線装置から前記第１のSSHコネクションを介して受信したマネジメントプレーンのデータまたは前記制御装置から前記第２のSSHコネクションを介して受信した前記マネジメントプレーンのデータを記録することをコンピュータに実行させるプログラム。
　１０　通信装置
　１１　通信部
　１２　データ記録部
　２０　無線装置
　３０　制御装置
　４０　通信端末
　５０　FH-Proxy
　６０　O-RU
　６１　O-RU
　６２　O-RU
　６３　O-RU
　７０　O-DU
　７１　O-DU
　７２　O-DU
　７３　O-DU
　８０　FH-Proxy
　８１　検証部
　９０　NMS
　１００　FH-Proxy

Claims (8)

  1. 　通信端末と無線通信を行う無線装置との間に第１のSSH（Secure Shell）コネクションを確立し、前記無線通信において用いられる信号に関するベースバンド処理を行う制御装置との間に第２のSSHコネクションを確立する通信手段と、
    　前記無線装置から前記第１のSSHコネクションを介して受信したマネジメントプレーンのデータまたは前記制御装置から前記第２のSSHコネクションを介して受信した前記マネジメントプレーンのデータを記録するデータ記録手段と、を備える通信装置。
  2. 　前記通信手段は、
    　前記無線装置から受信したマネジメントプレーンの第１のデータの宛先アドレスを前記制御装置を示す第１のアドレスへ変更して前記第１のデータを前記制御装置へ送信し、前記制御装置から受信したマネジメントプレーンの第２のデータの宛先アドレスを前記無線装置を示す第２のアドレスへ変更して前記第２のデータを前記無線装置へ送信する、請求項１に記載の通信装置。
  3. 　前記通信手段は、
    　前記制御装置へ送信する前記第１のデータの送信元アドレスを前記通信装置を示す第３のアドレスへ変更し、前記無線装置へ送信する前記第２のデータの送信元アドレスを前記通信装置を示す第４のアドレスへ変更する、請求項２に記載の通信装置。
  4. 　前記第１のデータ及び前記第２のデータに設定されるアドレスは、MAC（Media Access Control）アドレスである、請求項２又は３に記載の通信装置。
  5. 　前記通信手段は、
    　前記無線装置と前記制御装置との間において送信されるコントロールプレーン、ユーザプレーン、及び同期プレーンのうち少なくとも一つのデータを取得し、取得された前記データに設定される宛先アドレスは、前記マネジメントプレーンのデータを用いて指定される、請求項１乃至４のいずれか１項に記載の通信装置。
  6. 　前記データ記録手段は、
    　前記無線装置または前記制御装置から受信したコントロールプレーン、ユーザプレーン、及び同期プレーンのうち少なくとも一つのデータを記録し、
    　前記マネジメントプレーンのデータを用いて、前記コントロールプレーン、前記ユーザプレーン、及び前記同期プレーンのうち少なくとも一つのデータに正しい情報が設定されているかを判定する検証手段をさらに備える、請求項１乃至５のいずれか１項に記載の通信装置。
  7. 　通信端末と無線通信を行う無線装置との間に第１のSSH（Secure Shell）コネクションを確立し、
    　前記無線通信において用いられる信号に関するベースバンド処理を行う制御装置との間に第２のSSHコネクションを確立し、
    　前記無線装置から前記第１のSSHコネクションを介して受信したマネジメントプレーンのデータまたは前記制御装置から前記第２のSSHコネクションを介して受信した前記マネジメントプレーンのデータを記録する、データ記録方法。
  8. 　通信端末と無線通信を行う無線装置との間に第１のSSH（Secure Shell）コネクションを確立し、
    　前記無線通信において用いられる信号に関するベースバンド処理を行う制御装置との間に第２のSSHコネクションを確立し、
    　前記無線装置から前記第１のSSHコネクションを介して受信したマネジメントプレーンのデータまたは前記制御装置から前記第２のSSHコネクションを介して受信した前記マネジメントプレーンのデータを記録することをコンピュータに実行させるプログラムが格納された非一時的なコンピュータ可読媒体。
PCT/JP2021/002237 2020-03-11 2021-01-22 通信装置、データ記録方法、及び非一時的なコンピュータ可読媒体 WO2021181910A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP21768337.4A EP4007350A4 (en) 2020-03-11 2021-01-22 COMMUNICATION DEVICE, DATA RECORDING METHOD AND COMPUTER READABLE NON-TRANSITORY MEDIA
JP2022505816A JP7287569B2 (ja) 2020-03-11 2021-01-22 通信装置、データ記録方法、及びプログラム
CN202180020566.9A CN115280736A (zh) 2020-03-11 2021-01-22 通信设备、数据记录方法以及非暂时性计算机可读介质
US17/637,159 US12015523B2 (en) 2020-03-11 2021-01-22 Communication apparatus, data recording method, and non-transitory computer-readable medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020042467 2020-03-11
JP2020-042467 2020-03-11

Publications (1)

Publication Number Publication Date
WO2021181910A1 true WO2021181910A1 (ja) 2021-09-16

Family

ID=77671399

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/002237 WO2021181910A1 (ja) 2020-03-11 2021-01-22 通信装置、データ記録方法、及び非一時的なコンピュータ可読媒体

Country Status (5)

Country Link
US (1) US12015523B2 (ja)
EP (1) EP4007350A4 (ja)
JP (1) JP7287569B2 (ja)
CN (1) CN115280736A (ja)
WO (1) WO2021181910A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11510208B2 (en) * 2021-01-07 2022-11-22 T-Mobile Usa, Inc. Selection of open radio access network (RAN) components
WO2024049218A1 (ko) * 2022-08-30 2024-03-07 주식회사 쏠리드랩스 통신 시스템에서 타이밍 파라미터를 구성하기 위한 방법 및 그 장치

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012064007A (ja) * 2010-09-16 2012-03-29 Daiwa Institute Of Research Business Innovation Ltd 情報処理装置、通信中継方法およびプログラム
US20190245740A1 (en) * 2018-02-07 2019-08-08 Mavenir Networks, Inc. Management of radio units in cloud radio access networks
JP2020042467A (ja) 2018-09-10 2020-03-19 トモソウ・ジャパン株式会社 機器最適化配置システム、機器最適化配置支援システム、市場及び機器最適化配置システムによる市場の運営方法

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9003057B2 (en) * 2011-01-04 2015-04-07 Cisco Technology, Inc. System and method for exchanging information in a mobile wireless network environment
US8856910B1 (en) * 2011-08-31 2014-10-07 Palo Alto Networks, Inc. Detecting encrypted tunneling traffic
IN2014KN01446A (ja) * 2011-12-15 2015-10-23 Ericsson Telefon Ab L M
US8817733B2 (en) 2012-08-16 2014-08-26 Intel Corporation Mobile proxy for cloud radio access network
US8539567B1 (en) * 2012-09-22 2013-09-17 Nest Labs, Inc. Multi-tiered authentication methods for facilitating communications amongst smart home devices and cloud-based servers
WO2016154248A1 (en) * 2015-03-25 2016-09-29 Tevetron, Llc Communication network employing network devices with packet delivery over pre-assigned optical channels
JP6556320B2 (ja) 2015-12-17 2019-08-07 ホアウェイ・テクノロジーズ・カンパニー・リミテッド プロトコル変換方法および装置
US10165459B2 (en) * 2016-09-07 2018-12-25 Verizon Patent And Licensing Inc. Remote monitoring of fronthaul radio signals
US10498758B1 (en) * 2017-06-28 2019-12-03 Armis Security Ltd. Network sensor and method thereof for wireless network vulnerability detection
US10587434B2 (en) * 2017-07-14 2020-03-10 Nicira, Inc. In-band management interface with user space datapath
CN109803453B (zh) 2017-11-17 2023-07-07 华为技术有限公司 一种通信方法，通信设备及其通信系统
US10645603B2 (en) * 2018-03-12 2020-05-05 Wing Aviation Llc Portable autonomous vehicle connectivity platform
WO2020056183A1 (en) * 2018-09-13 2020-03-19 Commscope Technologies Llc Front-haul plug-and-play configuration for a c-ran
EP3841782A4 (en) * 2018-10-25 2022-06-08 CommScope Technologies LLC MULTI-CARRIER RADIO POINT FOR A CENTRALIZED RADIO ACCESS NETWORK
US10992554B2 (en) * 2018-12-07 2021-04-27 At&T Intellectual Property I, L.P. Intelligent data analytics collectors
US11368471B2 (en) * 2019-07-01 2022-06-21 Beijing Voyager Technology Co., Ltd. Security gateway for autonomous or connected vehicles
WO2021019631A1 (ja) * 2019-07-26 2021-02-04 株式会社Ｎｔｔドコモ 通信装置及び通信方法
CA3178890A1 (en) * 2020-05-18 2021-11-25 SimpliSafe, Inc. Operating wireless devices and image data systems
US20230096929A1 (en) * 2021-09-29 2023-03-30 Sage Electrochromics, Inc. System and method for long-term benchmarking for electrochromic glass
US20230137381A1 (en) * 2021-10-29 2023-05-04 Centre For Intelligent Multidimensional Data Analysis Limited System and method for detecting a facial apparatus

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012064007A (ja) * 2010-09-16 2012-03-29 Daiwa Institute Of Research Business Innovation Ltd 情報処理装置、通信中継方法およびプログラム
US20190245740A1 (en) * 2018-02-07 2019-08-08 Mavenir Networks, Inc. Management of radio units in cloud radio access networks
JP2020042467A (ja) 2018-09-10 2020-03-19 トモソウ・ジャパン株式会社 機器最適化配置システム、機器最適化配置支援システム、市場及び機器最適化配置システムによる市場の運営方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of EP4007350A4
UMESHUANNEAL : "Standardization trends for open and intelligent radio access networks O-RAN Front Hall Specifications Overview", NTT DOCOMO TECHNICAL JOURNAL, vol. 27, no. 1, 23 April 2019 (2019-04-23), pages 43 - 55, XP055902784 *

Also Published As

Publication number Publication date
JP7287569B2 (ja) 2023-06-06
US12015523B2 (en) 2024-06-18
US20220417097A1 (en) 2022-12-29
JPWO2021181910A1 (ja) 2021-09-16
EP4007350A1 (en) 2022-06-01
EP4007350A4 (en) 2022-11-23
CN115280736A (zh) 2022-11-01

Similar Documents

Publication Publication Date Title
US9071968B2 (en) Method, apparatus, and system for centralized 802.1X authentication in wireless local area network
US9871766B2 (en) Secure path determination between devices
WO2021181910A1 (ja) 通信装置、データ記録方法、及び非一時的なコンピュータ可読媒体
US7940658B2 (en) ERSPAN dynamic session negotiation
CN107580768B (zh) 报文传输的方法、装置和系统
US10897509B2 (en) Dynamic detection of inactive virtual private network clients
US20220353684A1 (en) System And Methods For Transit Path Security Assured Network Slices
EP3425945A1 (en) Methods and apparatus for a self-organized layer-2 enterprise network architecture
TW201943313A (zh) 使用設備設置協定（dpp）載入多存取點（多ap）設備
US9743338B2 (en) Methods and systems for communications through a slave gateway
US11388590B2 (en) Cryptographic security in multi-access point networks
US10485043B2 (en) Multi-connection access point
EP3932044B1 (en) Automatic distribution of dynamic host configuration protocol (dhcp) keys via link layer discovery protocol (lldp)
US20240154947A1 (en) Service assurance via federation-based network during roaming
US20200374957A1 (en) Multi-connection access point
JP6537115B2 (ja) ネットワーク装置、コンフィグ交換方法、保守交換方法、コンフィグ交換プログラム、および保守交換プログラム
US11671830B2 (en) Connecting access point to wireless multi-hop network based on a network role of the access point
US9992083B1 (en) System to detect network egress points
US20230396499A1 (en) Methods and systems for automatic open shortest path first (ospf) configuration
US11706644B2 (en) Access points with virtual clients
Corici et al. Enabling dynamic iot security domains: Cellular core network and device management meet authentication framework
JP7387033B2 (ja) パケット通信システム及び個別パケット中継装置
Gress et al. Deploying and troubleshooting Cisco wireless LAN controllers

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21768337

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022505816

Country of ref document: JP

ENP Entry into the national phase

Ref document number: 2021768337

Country of ref document: EP

Effective date: 20220225

NENP Non-entry into the national phase

Ref country code: DE