WO2020029261A1 - 一种上行接入的方法、设备 - Google Patents

一种上行接入的方法、设备 Download PDF

Info

Publication number
WO2020029261A1
WO2020029261A1 PCT/CN2018/100012 CN2018100012W WO2020029261A1 WO 2020029261 A1 WO2020029261 A1 WO 2020029261A1 CN 2018100012 W CN2018100012 W CN 2018100012W WO 2020029261 A1 WO2020029261 A1 WO 2020029261A1
Authority
WO
WIPO (PCT)
Prior art keywords
network device
terminal device
channel
signal
registration window
Prior art date
Application number
PCT/CN2018/100012
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 EP18929813.6A priority Critical patent/EP3813300A4/en
Priority to PCT/CN2018/100012 priority patent/WO2020029261A1/zh
Publication of WO2020029261A1 publication Critical patent/WO2020029261A1/zh
Priority to US17/158,119 priority patent/US11234062B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
    • H04Q11/0062—Network aspects
    • H04Q11/0071—Provisions for the electrical-optical layer interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
    • H04Q11/0062—Network aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
    • H04Q11/0062—Network aspects
    • H04Q2011/0064—Arbitration, scheduling or medium access control aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
    • H04Q11/0062—Network aspects
    • H04Q2011/0086—Network resource allocation, dimensioning or optimisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
    • H04Q11/0062—Network aspects
    • H04Q2011/0088—Signalling aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1301—Optical transmission, optical switches

Definitions

  • This application relates to the field of communications, and more specifically, to a method and device for uplink access.
  • FTTH fiber-to-the-home
  • PON passive optical network
  • ONU optical network unit
  • the International Telecommunications Union established the G.fast project to study the fiber-to-distribution point (FTTdp) scenario.
  • Digital subscriber lines digital subscribers
  • DSL copper wire access technologies
  • a large number of copper telephone lines are used to provide higher-speed Internet access between ONUs and end users.
  • the ITU studies the application scenarios that support shorter copper distances through the G.MGfast project.
  • the G.MGfast system can support point-to-muiti-point , P2MP).
  • a network device periodically sends an uplink random access indication signal to a user, and a newly-online user can send a random access signal within the indicated random access window in order to facilitate New users register online.
  • a network device periodically sends an uplink random access indication signal to a user, causing unnecessary resource overhead.
  • This application provides a method and device for uplink access, which can avoid the network device from periodically indicating the registration window in the P2MP working mode, thereby saving resource overhead and power consumption.
  • a method for uplink access includes: a network device receives instruction information sent by a terminal device when going online; and the network device sends an uplink on the first port according to the instruction information. Registration window instructions.
  • the instruction information is used to trigger the network device to send uplink registration window instruction information on the first port, and the uplink registration window instruction information is used to instruct the terminal device to send uplink registration information at the indicated registration window position.
  • the network device may distribute user data to the user equipment through a twisted pair (for example, a telephone line).
  • the network device may be TU-O.
  • the TU-O can distribute user data to user equipment through a twisted pair (for example, a telephone line), and can also receive data sent by the terminal equipment side.
  • the embodiment of the present application does not specifically limit the network device TU-O.
  • the network device in the G.fast project, the network device may be FTU-O.
  • the network device in the G.MGfast project, the network device may be MTU-O.
  • the terminal device in the embodiment of the present application may be a transceiver unit in a user or an enterprise, and may receive audio signals (analog signals) sent by a network device through a copper twisted pair cable, and may also send the converted analog signals through the twisted pair cable. Go to the network device side.
  • the terminal device may be a TU-R.
  • the embodiment of the present application does not specifically limit the terminal device TU-R.
  • the network device in the G.fast project, the network device may be FTU-R.
  • the network device in the G.MGfast project, the network device may be an MTU-R.
  • the indication information in the embodiment of the present application may be a specific signal that triggers the network device to send the indication information of the registration window.
  • the embodiment of the present application does not specifically limit the frequency band and signal form of the indication information sent by the terminal device when going online.
  • the indication signal may be a signal having the same frequency band and form as the R-TONES-REQ signal in the existing handshake toneset.
  • the indication signal may also be a signal having the same frequency band as the R-TONES-REQ signal in the existing handshake toneset but with a different shape (for example, an uplink registration window request signal).
  • the indication signal may also be another signal (for example, a registration window request signal) different from the frequency band of the R-TONES-REQ signal in the existing handshake toneset.
  • the indication information may also be a pseudo noise (PN) sequence or a ZC (zadoff) sequence carried in a certain time domain and a frequency domain.
  • the indication information may also be a signal with a certain energy in a fixed frequency and a fixed time.
  • terminal devices of different forms and frequency bands may send information on different channels.
  • the network equipment can receive the indication information in different channels.
  • the channel can be understood as a receiving processing channel inside the network device side.
  • the network device may receive the indication information sent by the terminal device in the embodiment of the present application, which is not specifically limited in this application.
  • the indication signal may also be another signal (for example, an uplink registration window request signal) other than the frequency band of the R-TONES-REQ signal in the existing handshake toneset
  • the network device may Receive the instruction information sent by the terminal device in a channel different from the handshake toneset.
  • the indication signal can be a signal having the same frequency band and form as the R-TONES-REQ signal in the existing handshake toneset
  • the network device can receive the instruction information sent by the terminal device in the handshake toneset of the first port .
  • the network device can also Receive instructions from a terminal device in the handshake and toneset of a port.
  • the network device receives, in a first channel of the first port, first indication information sent by the terminal device, where the first indication information is A signal with a different frequency band from the second channel.
  • the network device receives second instruction information sent by the terminal device in the second channel of the first port, and the second instruction The information is a signal having the same frequency band as the second channel.
  • the network device when the second indication information is a signal with the same frequency band as the R-TONES-REQ signal in the existing handshake protocol of the second channel, but with a different signal form
  • the network device sends the uplink registration window indication information in the first channel of the first port according to the first indication information.
  • the method further includes : The network device performs the handshake protocol process on a second channel of the first port.
  • a method for uplink access includes: when a terminal device is online, sending instruction information to a network device on a second port, the instruction information is used to trigger the network device to send an uplink on the first port.
  • Registration window instruction information the uplink registration window instruction information is used to instruct the terminal device to send uplink registration information at the indicated registration window position, and the second port corresponds to the first port on which the network device receives the instruction information ;
  • the terminal device receives, in the second port, uplink registration window indication information sent by the network device.
  • the terminal device sends first instruction information to the network device in a first channel of the second port, and the first instruction information is related to Signals with different frequency bands on the second channel.
  • the terminal device sends second instruction information to the network device in a second channel of the second port, and the second instruction information is related to The signals of the same frequency band on the second channel.
  • the method before the terminal device sends the second instruction information to the network device in the second channel of the second port, the method further includes: When a terminal device detects an existing handshake protocol signal on the second channel, the terminal device waits for the handshake protocol process to be completed.
  • the method further includes: if the terminal device does not receive the uplink registration window indication information on the second port before the timeout, The terminal device sends the second instruction information to the network device in a second channel of the second port.
  • the terminal device may continue to attempt to The first channel of the two ports sends first instruction information to the network device. In such a cycle, an attempt is made to send the first instruction information or the second instruction information.
  • the method before the terminal device sends instruction information to a network device, the method further includes: the terminal device is in a first channel of the second port When receiving the uplink registration window indication information, the terminal device sends registration information to the network device at the indicated registration window position.
  • a network device including: a first receiving module and a sending module,
  • the first receiving module is configured to receive instruction information sent by a terminal device when going online;
  • the sending module is configured to send uplink registration window instruction information on the first port according to the instruction information.
  • the instruction information is used to trigger the network device to send uplink registration window instruction information on the first port, and the uplink registration window instruction information is used to instruct the terminal device to send uplink registration information at the indicated registration window position.
  • the first receiving module is specifically configured to: receive the first instruction information sent by the terminal device in a first channel of the first port, and The first indication information is a signal different from a frequency band of the second channel.
  • the first receiving module is further specifically configured to receive a second instruction sent by the terminal device in the second channel of the first port.
  • Information, and the second indication information is a signal having the same frequency band as the second channel.
  • the sending module is specifically configured to send the uplink registration window indication information in the first channel of the first port according to the first indication information.
  • the sending module when the second information is a signal having the same form as the R-TONES-REQ signal in the existing handshake protocol of the second channel, the sending module further Configured to perform the handshake protocol process on a second channel of the first port.
  • a terminal device includes a first sending module and a first receiving module.
  • the first sending module is configured to send instruction information to a network device when going online;
  • the first receiving module is configured to receive, in the second port, uplink registration window indication information sent by the network device.
  • the first instruction information is used to trigger the network device to send uplink registration window instruction information on the first port, and the uplink registration window instruction information is used to instruct the terminal device to send uplink registration information at the indicated registration window position.
  • the second port corresponds to a first port on which the network device receives the indication information.
  • the first sending module is specifically configured to: the terminal device sends a first instruction to the network device in a first channel of the second port Information, the first indication information is a signal with a frequency band different from that of the second channel.
  • the first sending module is specifically configured to: the terminal device send a second instruction to the network device in a second channel of the second port Information, and the second indication information is a signal having the same frequency band as the second channel.
  • the terminal device further includes: a processing module
  • the processing module is configured to: when a terminal device detects an existing handshake protocol signal on the second channel, the terminal device waits for the handshake protocol process to be completed.
  • the terminal device further includes: a second sending module
  • the second sending module is specifically configured to: if the uplink registration window indication information is not received on the second port before the timeout, the terminal device sends a message to the second channel in the second channel of the second port.
  • the network device sends the second indication information.
  • the terminal device further includes: a second receiving module
  • the second receiving module is specifically configured to: when receiving the uplink registration window indication information in the first channel of the second port, the terminal device sends a registration to the network device at the indicated registration window position information.
  • a network device includes: a memory, a processor, and a transceiver.
  • the memory is configured to store a program; the processor is configured to execute a program stored in the memory, and when the program is executed, the processor executes the first aspect or any one of the first aspects through the transceiver.
  • the processor may be communicatively connected with the transceiver.
  • the memory may be used to store program code and data of the network device. Therefore, the memory may be a storage unit inside the processor, or an external storage unit independent of the processor, or a component including a storage unit inside the processor and an external storage unit independent of the processor.
  • the processor may be a general-purpose processor, and may be implemented by hardware or software.
  • the processor may be a logic circuit, integrated circuit, etc .; when implemented by software, the processor may be a general-purpose processor, realized by reading software codes stored in a memory, and the memory may be Integrated in the processor, it can be located outside the processor and stand alone.
  • the transceiver When the program is executed, the transceiver is configured to: receive instruction information sent by the terminal device when it is online;
  • the processor is configured to execute a program stored in the memory.
  • the transceiver hears the processor and performs the following steps: according to the instruction information, on the first port Send uplink registration window instructions.
  • the instruction information is used to trigger the network device to send uplink registration window instruction information in the first port, and the uplink registration window instruction information is used to instruct the terminal device to send uplink registration information at the indicated registration window position.
  • the transceiver is specifically configured to: receive, in a first channel of the first port, first indication information sent by the terminal device, where The first instruction information is a signal having a frequency band different from that of the second channel.
  • the transceiver is further specifically configured to: receive the second instruction information sent by the terminal device in the second channel of the first port,
  • the second instruction information is a signal having the same frequency band as the second channel.
  • the transceiver is specifically configured to send the uplink registration window indication information in the first channel of the first port according to the first indication information.
  • the transceiver when the second information is a signal having the same shape as the R-TONES-REQ signal in the existing handshake protocol of the second channel, the transceiver is specifically Configured to perform the handshake protocol process on a second channel of the first port.
  • a terminal device includes: a memory, a processor, and a transceiver.
  • the memory is configured to store a program; the processor is configured to execute a program stored in the memory, and when the program is executed, the processor executes the first aspect or any one of the first aspects through the transceiver.
  • the processor may be communicatively connected with the transceiver.
  • the memory may be used to store program code and data of the terminal device. Therefore, the memory may be a storage unit inside the processor, or an external storage unit independent of the processor, or a component including a storage unit inside the processor and an external storage unit independent of the processor.
  • the processor may be a general-purpose processor, and may be implemented by hardware or software.
  • the processor may be a logic circuit, integrated circuit, etc .; when implemented by software, the processor may be a general-purpose processor, realized by reading software codes stored in a memory, and the memory may be Integrated in the processor, it can be located outside the processor and stand alone.
  • the transceiver When the program is executed, the transceiver is configured to: send instruction information to the network device when going online;
  • the transceiver is further configured to receive, in the second port, uplink registration window indication information sent by the network device.
  • the instruction information is used to trigger the network device to send uplink registration window instruction information in the first port, and the uplink registration window instruction information is used to instruct the terminal device to send uplink registration information at the indicated registration window position.
  • the second port corresponds to a first port on which the network device receives the indication information.
  • the transceiver is specifically configured to: the terminal device sends the first instruction information to the network device in a first channel of the second port,
  • the first indication information is a signal different from a frequency band of the second channel.
  • the transceiver is specifically configured to: the terminal device sends second instruction information to the network device in a second channel of the second port,
  • the second instruction information is a signal having the same frequency band as the second channel.
  • the processor is configured to: when the terminal device listens to an existing handshake protocol signal on the second channel, the terminal device waits for the The handshake agreement process is complete.
  • the transceiver is further specifically configured to: in a case where the uplink registration window indication information is not received on the second port before the timeout, the terminal device forwards the request to the second port in the second channel of the second port.
  • the network device sends the second indication information.
  • the transceiver is further specifically configured to: when receiving the uplink registration window indication information in the first channel of the second port, The terminal device sends registration information to the network device at the indicated registration window position.
  • a chip including a memory, a processor, and a transceiver.
  • the processor may be communicatively connected with the transceiver.
  • the memory may be used to store program code and data of the network device. Therefore, the memory may be a storage unit inside the processor, or an external storage unit independent of the processor, or a component including a storage unit inside the processor and an external storage unit independent of the processor.
  • the processor may be a general-purpose processor, and may be implemented by hardware or software.
  • the processor may be a logic circuit, integrated circuit, etc .; when implemented by software, the processor may be a general-purpose processor, realized by reading software codes stored in a memory, and the memory may be Integrated in the processor, it can be located outside the processor and stand alone.
  • the transceiver executes the first aspect or any possible implementation manner of the first aspect through the processor.
  • a chip including a memory, a processor, and a transceiver.
  • the processor may be communicatively connected with the transceiver.
  • the memory may be used to store program code and data of the terminal device. Therefore, the memory may be a storage unit inside the processor, or an external storage unit independent of the processor, or a component including a storage unit inside the processor and an external storage unit independent of the processor.
  • the processor may be a general-purpose processor, and may be implemented by hardware or software.
  • the processor may be a logic circuit, integrated circuit, etc .; when implemented by software, the processor may be a general-purpose processor, realized by reading software codes stored in a memory, and the memory may be Integrated in the processor, it can be located outside the processor and stand alone.
  • the transceiver executes the second aspect or any possible implementation manner of the second aspect through the processor.
  • a computer-readable storage medium including a computer program, and when the computer program is run on a computer, the computer is implemented as described in the first aspect or any implementation manner of the first aspect. method.
  • a computer-readable storage medium including a computer program, and when the computer program is run on a computer, the computer is caused to execute the method described in the second aspect or any implementation manner of the second aspect.
  • a computer program product is provided, and when the computer program product runs on a computer, the computer is caused to execute the method as described in the first aspect or any implementation manner of the first aspect.
  • a computer program product is provided, and when the computer program product runs on a computer, the computer is caused to execute the method described in the second aspect or any one of the implementation manners of the second aspect.
  • a system including the foregoing terminal device and network device.
  • FIG. 1 is a schematic diagram of an application scenario of a G.MGfast device according to an embodiment of the present application.
  • FIG. 2 is a schematic diagram of a G.MGfast reference model according to an embodiment of the present application.
  • FIG. 3 is a schematic flowchart of an uplink access method according to an embodiment of the present application.
  • FIG. 4 is a schematic block diagram of a handshake protocol according to an embodiment of the present application.
  • FIG. 5 is a schematic flowchart of a possible network device in step 310 in FIG. 3.
  • FIG. 6 is a schematic diagram of a workflow of a possible terminal device in step 310 in FIG. 3.
  • FIG. 7 is a schematic diagram of a work flow of another possible terminal device in step 310 in FIG. 3.
  • FIG. 8 is a schematic diagram of a work flow of another possible network device in step 310 in FIG. 3.
  • FIG. 9 is a schematic diagram of a work flow of another possible terminal device in step 310 in FIG. 3.
  • FIG. 10 is a schematic diagram of a work flow of another possible terminal device in step 310 in FIG. 3.
  • FIG. 11 is a schematic diagram of a work flow of another possible network device in step 310 in FIG. 3.
  • FIG. 12 is a schematic diagram of a work flow of another possible terminal device in step 310 in FIG. 3.
  • FIG. 13 is a schematic block diagram of a network device 1300 according to an embodiment of the present application.
  • FIG. 14 is a schematic block diagram of a terminal device 1400 according to an embodiment of the present application.
  • FIG. 15 is a schematic block diagram of a network device 1500 according to an embodiment of the present application.
  • FIG. 16 is a schematic block diagram of a terminal device 1600 according to an embodiment of the present application.
  • Passive optical fiber network PON can refer to the use of optical fiber as the transmission medium between the central office equipment and the user equipment.
  • the PON may include: an optical line terminal (OLT), an optical distribution network (ODN), an optical network unit ONU, and the like.
  • OLT optical line terminal
  • ODN optical distribution network
  • OTN optical network unit
  • the devices in the PON are described in detail below.
  • Optical line terminal OLT It can be an important central office equipment. It can be connected to the front-end switch with a network cable and converted into optical signals.
  • the OLT can provide an interface for the ODN of the optical distribution network, can be connected to one or more ODNs, and can provide the necessary transmission mode for the interface required by the ONU of the optical network unit.
  • Optical distribution network ODN It can be an optical fiber network of PON equipment, which can provide an optical transmission channel between the OLT and the ONU.
  • Optical network unit ONU It may be a terminal device for fiber access (a device for fiber termination in a fiber access network), and may be located on the user side. According to the position of the ONU on the user side, the fiber access methods can be divided into the following: fiber to the home (FTTH), fiber to the building (FTTB), fiber to the roadside (fiber-to-curb, FTTC), fiber-to-the-office building (FTTO), fiber-to-the-zone (FTTZ), fiber-to-the-pole (FTTP), and so on. It should be noted that an optical network terminal (ONT) can also be regarded as an ONU.
  • FTTH fiber to the home
  • FTTB fiber to the building
  • FTTC fiber to the roadside
  • FTTO fiber-to-the-office building
  • FTTZ fiber-to-the-zone
  • FTTP fiber-to-the-pole
  • FTTH fiber-to-the-home
  • PON passive optical fiber network
  • ONUs can be set up in buildings, roadsides, office buildings, communities, poles, etc. (can correspond to the different fiber access methods mentioned above, for example, FTTB, FTTC, FTTO, FTTZ , FTTP, etc.), and can make full use of a large number of laid copper telephone lines to provide broadband access services for the "last mile" between ONUs and end users.
  • the International Telecommunication Union has established the G.fast project to study the fiber-to-distribution point (FTTdp) scenario, and can use copper lines such as digital subscriber lines (DSL)
  • FTTdp fiber-to-distribution point
  • DSL digital subscriber lines
  • the access technology has obvious advantages in terms of investment, operation and maintenance. A large number of copper telephone lines are used to provide higher-speed Internet access between the ONU and the end user.
  • the goal of the G.fast project can be to provide users with access rates up to 1Gbit / s.
  • the ITU studies the application scenarios that support shorter copper distances through the G.MGfast project.
  • the G.MGfast system can support point-to-muiti-point , P2MP).
  • G.MGfast equipment can be used to distribute network data on copper telephone lines to user equipment, which can provide higher-speed Internet access for user equipment.
  • FIG. 1 is a schematic diagram of an application scenario of a G.MGfast device according to an embodiment of the present application.
  • the application scenarios of this G.MGfast device may include: optical line terminal OLT110, optical distribution network ODN 120, 2 decentralized processing unit DPUs (for example, DPU 130, DPU 140), and each DPU may include optical Network unit ONU and G.MGfast equipment, each DPU can carry 2 users (for example, users carried under DPU 130 include: user 136, user 138, users carried under DPU 140 include: user 146, user 148).
  • the DPU 130 may be a scenario in which an ONU is set at a roadside (for example, FTTC technology), and the DPU 140 may be a scenario in which an ONU is set at a building 150 (for example, FTTB technology).
  • the embodiment of the present application does not limit the specific application scenarios of the G.MGfast device, and may also be the scenarios mentioned above such as FTTO, FTTO, FTTZ, and FTTP.
  • the optical line terminal OLT 110 can distribute user data to the decentralized processing unit DPU 130 through the optical fiber network through ODN 120.
  • the ONU and G.MGfast devices inside the DPU 130 distribute the user data on the copper wire 134 to the modem modem in the user 136 (modem can also be understood as the "cat" for the Internet in the user 136 home, and can be responsible for the connection between the analog and digital signals Conversion), and the user data can be distributed on the copper wire 132 to the modem in the user 138.
  • the optical line terminal OLT 110 can distribute user data to the decentralized processing unit DPU 140 through the optical fiber network through ODN 120.
  • the ONU and G.MGfast devices inside the DPU 140 distribute user data on the copper wire 142 to the modem in the user 146 in the building, and can distribute the user data on the copper wire 144 to the modem in the user 148.
  • FIG. 2 is a schematic diagram of a G.MGfast reference model according to an embodiment of the present application.
  • the G.MGfast reference model can include: OLT 110, ODN 120, DPU 130, port physical layer (PHY) 232, and transceiver unit (transceiver unit at the optical network unit, TU-O). ) 234, twisted pair (wire) 240, user 136, PHY 238, transceiver unit (remote site, remote site (TU-R) 236) at the remote site.
  • the optical line terminal OLT 110 can transmit data to the decentralized processing unit DPU 130 through the optical distribution network ODN 120.
  • the physical layer PHY 232 of the port in the DPU 130 can be used as an access network, and the received data can be distributed to the modem 136 of the user 136 on the twisted pair 240 through the TU-O 234.
  • the modems of 136 users can receive data through TU-R 236, and can send the data to the computer.
  • the decentralized processing unit DPU 130 can be used as a network device and can distribute user data to the user 136 through a twisted pair.
  • TU-O 234 and TU-R 236 can be used as the transceiver unit in DPU 130 and user 136, respectively.
  • the DPU 130 may have multiple ports (which may also be understood as including multiple TU-Os), and each port may carry one or more users 136 below.
  • each port may carry one or more users 136 below.
  • P2P point-to-point
  • the port can support a point-to-point (P2P) protocol, and the DPU 130 and the user 136 can work in a P2P working mode.
  • the port can support the P2MP protocol, and the DPU 130 and the users 136 can work in the P2MP working mode.
  • terminal devices and network devices that support the P2MP working mode can also support the P2P working mode.
  • the specific mode in which the terminal equipment and network equipment work can be negotiated by the two parties. The detailed description will be described below in conjunction with specific embodiments, and will not be described again here.
  • the user 136 can perform random uplink access through TU-R 236 when it needs to go online.
  • the TU-O 234 in the DPU 130 can respond to the registration response of the user 136 according to the supported working mode, thereby completing the registration.
  • the TU-O 234 (as a network device) in the DPU 130 needs to send a window indication of uplink random access to the TU-R 236 (as a terminal device) in the user 136.
  • the terminal device can The window location sends a message carrying the ID, and the network device can send a response message carrying the ID in the downlink channel, and further authenticate to determine the conflict, thereby completing the user registration.
  • a network device in a P2MP working mode, periodically indicates a random access window position to the network device, so that a terminal device can send a registration message at a specified window position.
  • the network device since the number of terminal devices carried under the network device is small and the probability of random access is low, the network device periodically instructs the registration window to cause resource waste.
  • the terminal equipment carried under the network device is not working, the sending end of the network device needs to remain in the working state, so the network device periodically instructs the registration window to cause problems such as power consumption and large power consumption.
  • An uplink access method provided in the embodiments of the present application can avoid a network device from periodically indicating a registration window, which can save resource overhead and power consumption.
  • FIG. 3 is a schematic flowchart of an uplink access method according to an embodiment of the present application.
  • the method shown in FIG. 3 may include steps 310-320. Steps 310-320 are described in detail below.
  • Step 310 The network device receives the instruction information sent by the terminal device when going online.
  • the network device may distribute user data to the user equipment through a twisted pair (for example, a telephone line).
  • the network device may be TU-234 shown in FIG. 2.
  • the TU-O 234 can distribute user data to user equipment through a twisted pair (for example, a telephone line), and can also receive data sent by the terminal equipment side.
  • the embodiment of the present application does not specifically limit the network device TU-O.
  • the network device in the G.fast project, the network device may be FTU-O.
  • the network device in the G.MGfast project, the network device may be MTU-O.
  • the terminal device in the embodiment of the present application may be a transceiver unit in a user or an enterprise, and may receive audio signals (analog signals) sent by a network device through a copper twisted pair cable, and may also send the converted analog signals through the twisted pair cable. Go to the network device side.
  • the terminal device may be TU-R 236 shown in FIG. 2.
  • the embodiment of the present application does not specifically limit the terminal device TU-R.
  • the network device in the G.fast project, the network device may be FTU-R.
  • the network device in the G.MGfast project, the network device may be an MTU-R.
  • the terminal device When the terminal device needs to go online, it can send instruction information to the network device, and the instruction information can be used to trigger the network device to send the registration window instruction information to the terminal device. If the terminal device can listen to the registration window indication information sent by the network device, the terminal device can perform uplink registration according to the position of the registration window indicated by the network device. After the terminal device is successfully registered, it may enter a subsequent initialization process, such as a handshake process. The handshake process will be described in detail with reference to FIG. 4, and will not be repeated here.
  • a handshake process will be described in detail with reference to FIG. 4, and will not be repeated here.
  • the first indication information in the embodiment of the present application may be a specific signal that triggers the network device to send the indication information of the registration window, and the embodiment of the present application does not specifically limit the frequency band and signal form of the indication information sent by the terminal device when going online.
  • the indication signal may be a signal with the same frequency band and shape as the far-end subcarrier request R-TONES-REQ signal in the existing handshake subcarrier set handshake and toneset.
  • the indication signal may also be a signal having the same frequency band as the R-TONES-REQ signal in the existing handshake toneset but with a different shape (for example, an uplink registration window request signal).
  • the indication signal may also be another signal (for example, a registration window request signal) different from the frequency band of the R-TONES-REQ signal in the existing handshake toneset.
  • the indication information may be a pseudo noise (PN) sequence or a Zadoff-Zhu (ZC) sequence carried in a certain time and frequency domain.
  • the indication information may also be a signal with a certain energy in a fixed frequency and a fixed time.
  • terminal devices of different forms and frequency bands may send information on different channels.
  • the network equipment can receive the indication information in different channels.
  • the channel can be understood as a receiving processing channel inside the network device side.
  • the network device may Receive the uplink registration window request signal sent by the terminal device in a channel different from the handshake toneset.
  • the indication signal can be a signal with the same frequency band and form as the R-TONES-REQ signal in the existing handshake toneset
  • the network device can receive the R- from the terminal device in the handshake toneset of the first port. TONES-REQ signal.
  • the network device can also A handshake toneset of a port receives a registration window request signal sent by a terminal device. Details will be described below with reference to FIGS. 5 to 12, and details are not described herein again.
  • Step 320 The network device sends the uplink registration window instruction information to the terminal device according to the instruction information.
  • the network device may send the uplink registration window instruction information to the terminal device according to the received instruction information.
  • the terminal device may send uplink registration information at the indicated registration window position, thereby entering the P2MP working mode.
  • the embodiment of the present application does not limit the implementation manner of the network device according to the uplink registration window indication information sent to the terminal device.
  • the network device may send the uplink registration window indication information in a channel (which can be understood as a P2MP downlink broadcast channel) in the first port that is different from the handshake toneset.
  • the network device may also send uplink registration window indication information in a handshake toneset in the first port.
  • FIG. 4 is a schematic block diagram of a handshake protocol according to an embodiment of the present application.
  • the handshake protocol process may include three phases: chain establishment 410, handshake message interaction 420, and chain disassembly 430.
  • the handshake interaction protocol will be described in detail below using chain building 410 as an example.
  • TU-R is initially in a transmission-quiet state (for example, the R-SILENT0 signal), and TU-O is also initially in a transmission-quiet state (for example, the C-SILENT1 signal).
  • the TU-R can start a program by sending one or more signals in its signal family (eg, R-TONES-REQ signal), the phases of which are inverted every 16ms.
  • the TU-O detects the R-TONES-REQ signal sent by the TU-R, the TU-O can respond by sending one or more signals in its signal family (for example, the C-TONES signal).
  • the TU-R After the TU-R detects the C-TONES signal sent by the TU-O, the TU-R can maintain a transmission silence state (for example, the R-SILENT1 signal) of 50ms to 500ms. After that, the TU-R can only send its signal A signal in the family (for example, the R-TONE1 signal). After the TU-O detects the R-TONE1 signal sent by the TU-R, the TU-O can respond by sending a GALF signal on a modulated carrier (for example, a C-GALF1 signal).
  • a transmission silence state for example, the R-SILENT1 signal
  • the TU-O can respond by sending a GALF signal on a modulated carrier (for example, a C-GALF1 signal).
  • the TU-R After the TU-R detects the C-TONES signal sent by the TU-O, the TU-R can send a FLAG signal (for example, an R-FLAG1 signal) on a modulated carrier. After the TU-O detects the R-FLAG1 signal sent by the TU-R, the TU-O can respond by sending a GALF signal on the modulated carrier (for example, the C-FLAG1 signal). After the TU-R detects the C-FLAG1 signal sent by the TU-O, the TU-R can perform the first data transmission.
  • a FLAG signal for example, an R-FLAG1 signal
  • the TU-O After the TU-O detects the R-FLAG1 signal sent by the TU-R, the TU-O can respond by sending a GALF signal on the modulated carrier (for example, the C-FLAG1 signal).
  • the TU-R After the TU-R detects the C-FLAG1 signal sent by the TU-O
  • step 310 when the indication signal sent by the terminal device is another signal with a different frequency band from the R-TONES-REQ signal in the existing handshake toneset (for example, when the uplink registration window request signal), the network device may receive the uplink registration window request signal sent by the terminal device in a channel (a P2MP channel) different from the handshake toneset of the first port.
  • a P2MP channel a channel whose first port is different from the handshake toneset
  • the network device may also listen in the handshake toneset of the first port whether there is an R-TONES-REQ signal in the handshake protocol sent by the terminal device. If the network device can receive the R-TONES-REQ signal sent by the terminal device in the handshake and toneset of the first port, the network device can enter the P2P working mode.
  • P2P devices and P2MP devices can be compatible at the same time.
  • the network device may receive the specific implementation of the uplink registration window request signal sent by the terminal device in an uplink channel (also understood as a P2MP uplink channel) of the first port that is different from the handshake toneset.
  • an uplink channel also understood as a P2MP uplink channel
  • FIG. 5 is a schematic flowchart of a possible network device in step 310 in FIG. 3.
  • the method in FIG. 5 may include steps 510-570. Steps 510-570 are described in detail below.
  • the network device in FIG. 5 may correspond to the TU-O 234 shown in FIG. 2, and the following uses the working process of the TU-O as an example for detailed description.
  • a channel different from the handshake toneset is referred to as a first channel.
  • step 510 the TU-O detects the handshake toneset and the first channel simultaneously.
  • TU-O can listen to the handshake and toneset of a port and the first channel at the same time after power-on.
  • Step 520 Whether the TU-O can detect a specific signal in the handshake toneset or the first channel.
  • the TU-O may perform step 530. If the TU-O does not detect a specific signal in the handshake toneset or the first channel, the TU-O may continue to perform step 510 to re-listen the handshake toneset and the first channel.
  • Step 530 Whether the TU-O can detect a specific signal in the handshake toneset.
  • the TU-O can detect a specific signal sent by the terminal device (for example, the TU-R mentioned above) in the handshake toneset, for example, the R-TONES-REQ signal shown in FIG. 4, the TU-O can Go to step 540. If the TU-O does not detect the specific signal sent by the terminal device in the handshake toneset, the TU-O detects the specific signal sent by the terminal device in the first channel, for example, the uplink registration window request signal, the TU-O Proceed to step 550.
  • a specific signal sent by the terminal device for example, the TU-R mentioned above
  • the TU-O can Go to step 540.
  • the TU-O does not detect the specific signal sent by the terminal device in the handshake toneset, the TU-O detects the specific signal sent by the terminal device in the first channel, for example, the uplink registration window request signal, the TU-O Proceed to step 550.
  • Step 540 the TU-O enters the P2P working mode.
  • the TU-O can detect a specific signal in the handshake toneset (for example, the R-TONES-REQ signal shown in Figure 4), the TU-O can enter the P2P working mode and can continue to complete the subsequent handshake interaction protocol .
  • a specific signal in the handshake toneset for example, the R-TONES-REQ signal shown in Figure 4
  • Step 550 The TU-O sends an uplink registration window indication signal in the first channel.
  • the TU-O can detect a specific signal (for example, an uplink registration window request signal) sent by the TU-R in the first channel, the TU-O can send an uplink registration window indication signal in the first channel.
  • the uplink registration window indication signal may indicate that the TU-R can send uplink registration information at a specified window position.
  • the TU-O may also send a training sequence, which may be used for synchronization and training of the downlink channel of the TU-R.
  • Step 560 Determine whether the new user is successfully registered.
  • the TU-O can detect the uplink registration information sent by the TU-R within the indicated registration window and can respond to the correctly parsed uplink registration information, the TU-O can complete the registration of the new user and can proceed to step 570 to work In P2MP working mode.
  • the TU-O may proceed to step 510 to re-listen the handshake toneset and the first channel.
  • Step 570 TU-O designates a newly registered user to complete the handshake process, and performs the first channel detection.
  • TU-O After entering the P2MP working mode, TU-O can assign an ID to the TU-R that has been successfully registered.
  • the TU-O may specify that the TU-R enters a subsequent initialization process, for example, a handshake protocol process.
  • the subsequent TU-O may perform step 550 and only detect whether there is a specific signal sent by the TU-R in the first channel. And you can follow the steps 550-570 to complete the registration of the new user.
  • the network device provided in the embodiment of the present application can avoid periodically instructing a registration window in a P2MP working mode, thereby saving resource overhead and power consumption.
  • the network device can also be compatible with both P2P working mode devices and P2MP working mode devices.
  • the terminal device shown in FIG. 5 receiving an uplink registration window request signal sent by a terminal device (for example, TU-R) in a channel (a P2MP channel) different from the handshake toneset of the first port.
  • a terminal device for example, TU-R
  • a P2MP channel a channel different from the handshake toneset of the first port.
  • the terminal device may send an uplink registration window request signal in a channel different from the handshake toneset, and may send uplink registration information according to the registration window position indicated by the network device.
  • the terminal device may first listen to whether there is registration window indication information sent by the network device, and if the terminal device can listen to the window indication information, it may send uplink registration information according to the registration window position. If the terminal device does not hear the window indication information, the terminal device may send an uplink registration window request signal in a channel different from the handshake toneset, and may perform uplink registration according to the registration window position indicated by the network device.
  • the terminal device may send the uplink registration window request signal in a specific channel different from the handshake toneset.
  • the example of FIG. 6 is only for helping those skilled in the art to understand the embodiments of the present application, and is not intended to limit the embodiments of the application to the specific values or specific scenarios shown. Those skilled in the art can obviously make various equivalent modifications or changes according to the example of FIG. 6 given in the text, and such modifications and changes also fall within the scope of the embodiments of the present application.
  • FIG. 6 is a schematic diagram of a workflow of a possible terminal device in step 310 in FIG. 3.
  • the method in FIG. 6 may include steps 610-660. Steps 610-660 are described in detail below.
  • terminal device in FIG. 6 may correspond to the TU-R 236 shown in FIG. 2, and the following uses the working process of the TU-R as an example for detailed description.
  • a channel different from the handshake toneset is referred to as a first channel.
  • Step 610 Determine whether the TU-R supports the P2MP working mode.
  • the TU-R After the TU-R is powered on, it can determine whether the TU-R supports the P2MP working mode. If the TU-R does not support the P2MP working mode (supports the P2P working mode), step 615 may be performed. If the TU-R supports the P2MP working mode, step 620 may be performed.
  • step 615 the TU-R enters the P2P working mode.
  • the TU-R can perform handshake protocol interaction based on the P2P working mode when it is determined that the P2MP working mode is not supported (supporting the P2P working mode).
  • Step 620 The TU-R sends a specific signal in the first channel.
  • the TU-R can send a specific signal in the first channel.
  • the specific signal may be uplink registration window request information.
  • the specific signal may be a PN sequence or a ZC sequence carried in a certain time and frequency domain, or a signal with a certain energy in a fixed frequency band and a fixed time.
  • Step 625 The TU-R listens to the first channel.
  • TU-R can listen to the first channel after sending a specific signal in the first channel.
  • Step 630 Determine whether the TU-R can detect the uplink registration window indication signal before timeout.
  • the TU-R can detect the uplink registration window indication signal sent by the TU-O before the timeout, the TU-R can perform steps 635-645.
  • the TU-R may perform steps 650-660.
  • the following describes the specific implementation manner that the TU-R can detect the uplink registration window indication signal sent by the TU-O in FIG. 5 before timeout in conjunction with steps 635-645.
  • Step 635 The TU-R sends registration information.
  • the TU-R After the TU-R can detect the uplink registration window indication signal sent by the TU-O in FIG. 5 before timeout, it can send registration information at the position of the uplink registration window designated by the TU-O in FIG. 5.
  • the registration information sent by the TU-R at the designated registration window position may include, but is not limited to: an ID uniquely identified by the TU-R (for example, a media access control (MAC) address), cyclic redundancy calibration Inspection (cyclic redundancy check, CRC) and other information.
  • an ID uniquely identified by the TU-R for example, a media access control (MAC) address
  • MAC media access control
  • CRC cyclic redundancy calibration Inspection
  • Step 640 Determine whether the TU-R is successfully registered.
  • the TU-R After the TU-R sends the registration information at the position of the uplink registration window designated by the TU-O in FIG. 4, it can determine whether the response message sent by the TU-O can be correctly received.
  • step 645 may be performed.
  • step 620 may be performed again.
  • step 645 the TU-R executes the subsequent interaction according to the TU-O and enters the data phase (show time).
  • the TU-R can obtain the ID assigned by the TU-O in FIG. 5 and can enter the subsequent initialization process according to the TU-O's indicated or predefined mode, for example, the handshake protocol process. And you can enter show time after initialization.
  • show time can be understood as that the TU-O and TU-R have completed the initialization process and can start sending data on the bearer channel.
  • the following describes the specific implementation manner in which the TU-R can not detect the uplink registration window indication signal sent by the TU-O in FIG. 5 before timeout in conjunction with steps 650-665.
  • step 650 the counter is incremented by one.
  • the timeout counter may be incremented by one.
  • Step 655 Determine whether the counter exceeds a threshold.
  • the TU-R may perform step 620 again.
  • the TU-O may not support the P2MP working mode, and the TU-R may perform step 660.
  • Step 660 The TU-R performs a P2P-based handshake interaction.
  • TU-R can send a handshake signal (for example, R-TONES-REQ signal) to TU-O after the counter has not received the uplink registration window indication signal sent by TU-O after exceeding the threshold, and can enter P2P Operating mode. And can continue to complete the subsequent handshake interaction protocol.
  • a handshake signal for example, R-TONES-REQ signal
  • the terminal device provided in the embodiment of the present application can avoid the network device from periodically indicating the registration window in the P2MP working mode, thereby saving the resource overhead and power consumption of the network device.
  • the terminal device can also be compatible with both P2P working mode devices and P2MP working mode devices.
  • the terminal device can first listen for the registration window indication information sent by the network device. If the window indication information is not intercepted, The terminal device sends a specific implementation manner of the first instruction information in a channel different from the handshake toneset.
  • FIG. 7 is only for helping those skilled in the art to understand the embodiments of the present application, and is not intended to limit the embodiments of the application to the specific values or specific scenarios shown. Those skilled in the art can obviously make various equivalent modifications or changes according to the example of FIG. 7 given in the text, and such modifications and changes also fall within the scope of the embodiments of the present application.
  • FIG. 7 is a schematic diagram of a work flow of another possible terminal device in step 310 in FIG. 3.
  • the method in FIG. 7 may include steps 710-770. Steps 710-770 are described in detail below.
  • terminal device in FIG. 7 may correspond to the TU-R 236 shown in FIG. 2, and the following takes the working process of the TU-R as an example for detailed description.
  • a channel different from the handshake toneset is referred to as a first channel.
  • Step 710 Determine whether the TU-R supports the P2MP working mode.
  • step 715 may be performed.
  • step 720 may be performed.
  • step 715 the TU-R enters the P2P working mode.
  • the TU-R can perform handshake protocol interaction based on the P2P working mode when it is determined that the P2MP working mode is not supported (supporting the P2P working mode).
  • Step 720 The TU-R listens to the first channel.
  • TU-R can first listen to the first channel when it judges that it supports the P2MP working mode.
  • Step 725 Determine whether the TU-R can detect the uplink registration window indication signal before timeout.
  • the TU-R can detect the uplink registration window indication signal sent by the TU-O in the first channel before the timeout, the TU-R can perform steps 735-740.
  • the TU-R may perform steps 745-750.
  • Step 730 The TU-R sends registration information.
  • the TU-R After the TU-R can detect the uplink registration window indication signal sent by the TU-O in FIG. 5 before timeout, it can send registration information at the position of the uplink registration window designated by the TU-O in FIG.
  • the registration information sent by the TU-R at the designated registration window position may include, but is not limited to, information such as an ID (for example, a MAC address) uniquely identified by the TU-R, and a cyclic redundancy check (CRC).
  • ID for example, a MAC address
  • CRC cyclic redundancy check
  • Step 735 Determine whether the TU-R is successfully registered.
  • the TU-R After the TU-R sends the registration information at the position of the uplink registration window designated by the TU-O in FIG. 4, it can determine whether the response message sent by the TU-O can be correctly received.
  • step 745 may be performed.
  • step 720 may be performed again.
  • step 740 the TU-R executes the subsequent interaction according to the TU-O and enters the show time.
  • the TU-R can obtain the ID assigned by the TU-O in FIG. 5 and can enter the subsequent initialization process according to the TU-O's indicated or predefined mode, for example, the handshake protocol process. And you can enter show time after initialization.
  • show time can be understood as that the TU-O and TU-R have completed the initialization process and can start sending data on the bearer channel.
  • Step 745 The TU-R sends a specific signal in the first channel.
  • the TU-R may not detect the uplink registration window indication signal sent by the TU-O before the timeout, and the TU-R may send a specific signal in the first channel.
  • the specific signal may be uplink registration window request information.
  • the specific signal may be a PN sequence or a ZC sequence carried in a certain time and frequency domain, or a signal with a certain energy in a fixed frequency band and a fixed time.
  • Step 750 The TU-R listens to the first channel.
  • TU-R can listen to the first channel after sending a specific signal in the first channel.
  • Step 755 Determine whether the TU-R can detect the uplink registration window indication signal before timeout.
  • the TU-R can detect the uplink registration window indication signal sent by the TU-O in the first channel before the timeout, the TU-R can perform steps 730-735.
  • the TU-R may perform steps 760-765.
  • the TU-R can detect the uplink registration window indication signal sent by the TU-O in FIG. 5 before the timeout.
  • steps 730-735 please refer to the description of steps 730-735 above, which will not be repeated here.
  • the following describes the specific implementation manner in which the TU-R can not detect the uplink registration window indication signal sent by the TU-O in FIG. 5 before timeout in conjunction with steps 760-770.
  • step 760 the counter is incremented by one.
  • the timeout counter may be incremented by one.
  • Step 765 Determine whether the counter exceeds a threshold.
  • the TU-R may perform step 720 again.
  • the TU-O may not support the P2MP working mode, and the TU-R may perform step 770.
  • Step 770 The TU-R performs a P2P-based handshake interaction.
  • TU-R can send a handshake signal (for example, R-TONES-REQ signal) to TU-O after the counter has not received the uplink registration window indication signal sent by TU-O after exceeding the threshold, and can enter P2P Operating mode. And can continue to complete the subsequent handshake interaction protocol.
  • a handshake signal for example, R-TONES-REQ signal
  • the terminal device provided in FIG. 7 can listen to the registration window indication information sent by the network device based on FIG. 6. If the window indication information is heard, the new user can go online to register directly, which can simplify the new user. Registration process for random access.
  • the terminal device provided in the embodiment of the present application can avoid the network device from periodically indicating the registration window in the P2MP working mode, thereby saving the resource overhead and power consumption of the network device.
  • the terminal device can also be compatible with both P2P working mode devices and P2MP working mode devices.
  • the network device can also receive the R-TONES-REQ signal or registration window sent by the terminal device in the handshake and toneset of the first port. Request signal.
  • the indication signal may be a signal having the same frequency band and shape as the R-TONES-REQ signal in the existing handshake toneset (for example, the R-TONES-REQ signal) or the same as the R-
  • the network device can also receive the R-TONES-REQ signal or registration window sent by the terminal device in the handshake and toneset of the first port. Request signal.
  • FIG. 8 is a schematic diagram of a work flow of another possible network device in step 310 in FIG. 3.
  • the method of FIG. 8 may include steps 810-865. Steps 810-865 are described in detail below.
  • the network device in FIG. 8 may correspond to the TU-O 234 shown in FIG. 2, and the TU-O working process is taken as an example for detailed description below.
  • a channel different from the handshake toneset is referred to as a first channel.
  • step 810 power is started.
  • Step 812 TU-O detects a handshake toneset.
  • TU-O can listen to a port as a handshake toneset (also known as a P2P channel).
  • a handshake toneset also known as a P2P channel.
  • Step 815 Determine whether the TU-O can detect a specific signal in the handshake toneset.
  • the TU-O may perform step 820.
  • the TU-O may perform step 810 again.
  • the form of the specific signal detected in the handshake toneset may be, for example, an R-TONES-REQ signal.
  • the R-TONES-REQ signal in the handshake and toneset in the embodiment of the present application can be used to indicate the signal that TU-R triggers TU-O to send an uplink registration window request (triggers TU-O to enter the P2MP working mode), and can also be used to indicate TU -R signal that triggers TU-O to enter P2P working mode. This application does not specifically limit this.
  • Step 820 The TU-O sends an uplink registration window indication signal, and at the same time, performs interaction based on the P2P in the handshake channel according to the protocol.
  • the TU-O after the TU-O can detect a specific signal in the handshake toneset, it can send an uplink registration window indication signal in the first channel, and can send the uplink registration window indication signal in the handshake toneset. Be specific.
  • TU-O After sending the uplink registration window indication signal, TU-O can simultaneously interact based on P2P in the handshake and toneset at the same time.
  • TU-O can be compatible with both P2MP devices and P2P devices, and TU-R can choose either P2MP working mode or P2P working mode.
  • the TU-O may also send a training sequence before sending the uplink registration window indication signal, and the training sequence may be used for the downlink channel of the terminal device (for example, TU-R). Sync and train.
  • Step 825 Determine whether the TU-O can receive the C-SLIENT1, and then detect the R-TONE1 signal.
  • TU-O can first receive the C-SLIENT1 signal sent by TU-R in handshake and toneset, and then receive the R-TONE1 signal sent by TU-R (indicating that TU-R may only support P2P working mode), TU-O can Go to step 830. The TU-O can enter the P2P working mode, and can choose to perform subsequent handshake interaction according to the handshake channel flow.
  • the TU-O may perform step 835.
  • the TU-O can detect whether there is uplink registration information sent by the TU-R at the indicated position of the uplink registration window.
  • Step 830 TU-O closes the first channel and enters the P2P working mode.
  • TU-O After receiving the R-TONE1 signal sent by TU-R in the handshake toneset, TU-O can close the first channel, enter the P2P working mode, and can continue to complete the subsequent handshake interaction protocol.
  • Step 835 Determine whether the new user is successfully registered.
  • the TU-O can detect whether there is uplink registration information sent by the TU-R at the position of the indicated uplink registration window.
  • the TU-O can detect the uplink registration information sent by the TU-R within the indicated registration window and can respond to the correctly resolved uplink registration information, the TU-O can complete the registration of the new user.
  • the TU-O may proceed to step 840 and work in a P2MP working mode.
  • the TU-O may re-enter step 810 and may listen to the handshake toneset again.
  • Step 840 Close the handshake process and enter the P2MP working mode.
  • the TU-O can detect the uplink registration information sent by the TU-R within the indicated registration window and can respond to the correctly resolved uplink registration information, the TU-O can complete the registration of the new user. TU-O can close the handshake process and enter P2MP working mode.
  • TU-O After entering the P2MP working mode, TU-O can assign an ID to the TU-R that has been successfully registered.
  • the TU-O may specify that the TU-R enters a subsequent initialization process, for example, a handshake protocol process.
  • the TU-O can perform steps 845-865. After listening to a specific signal in the handshake toneset, it can only send the uplink registration window on the first channel. Indication signal.
  • Step 845 TU-O detects a handshake toneset.
  • TU-O can listen to the handshake and toneset of a port.
  • Step 850 Determine whether the TU-O can detect a specific signal in the handshake toneset.
  • the TU-O may perform step 855.
  • the TU-O may perform step 845 again.
  • Step 855 the TU-O sends an uplink registration window indication signal on the first channel.
  • the TU-O may send an uplink registration window indication signal only after the TU-O detects a specific signal in the handshake toneset. No longer respond to signals from unspecified handshake.
  • Step 860 Determine whether the new user is successfully registered.
  • the TU-O can detect the uplink registration information sent by the TU-R within the indicated registration window and can respond to the correctly resolved uplink registration information, the TU-O can complete the registration of the new user and proceed to step 865.
  • the TU-O may re-enter step 845 to re-listen the handshake toneset.
  • step 865 TU-O designates a newly registered user to complete the handshake process and perform the first channel detection.
  • TU-O After entering the P2MP working mode, TU-O can assign an ID to the TU-R that has been successfully registered.
  • the TU-O may specify that the TU-R enters a subsequent initialization process, for example, a handshake protocol process.
  • the network device provided in the embodiment of the present application can avoid periodically instructing a registration window in a P2MP working mode, thereby saving resource overhead and power consumption.
  • the network device can also be compatible with both P2P working mode devices and P2MP working mode devices.
  • the terminal device Corresponding to the network device shown in FIG. 8 receiving the R-TONES-REQ signal sent by the terminal device (for example, TU-R) in the handshake toneset of the first port, the terminal device sends the R-TONES-REQ signal in the embodiment of the present application.
  • the terminal device may directly send an R-TONES-REQ signal in the handshake toneset after determining that it can support the P2MP working mode.
  • the terminal device may first listen to whether there is indication information of the registration window sent by the network device, and if not, the terminal device sends an R-TONES-REQ signal in the handshake toneset.
  • FIG. 9 is a schematic diagram of a work flow of another possible terminal device in step 310 in FIG. 3.
  • the method of FIG. 9 may include steps 910-975. Steps 910-975 are described in detail below.
  • terminal device in FIG. 9 may correspond to the TU-R 236 shown in FIG. 2, and the following uses the working process of the TU-R as an example for detailed description.
  • a channel different from the handshake toneset is referred to as a first channel.
  • Step 910 Determine whether the TU-R supports the P2MP working mode.
  • the TU-R After the TU-R is powered on, it can determine whether the TU-R supports the P2MP working mode. If the TU-R does not support the P2MP working mode (supports the P2P working mode), step 915 may be performed. If the TU-R supports the P2MP working mode, step 920 may be performed.
  • step 915 the TU-R enters the P2P working mode.
  • the TU-R can perform handshake protocol interaction based on the P2P working mode when it is determined that the P2MP working mode is not supported (supporting the P2P working mode).
  • Step 920 The TU-R listens to the downlink handshake and toneset.
  • TU-R can determine whether to support the P2MP working mode, first listen to the handshake toneset, and see if there are other handshake protocol signals in the handshake toneset.
  • the TU-R may first listen to whether there are other handshake protocol signals being exchanged in the handshake toneset. If there is a handshake protocol signal that is being interacted in the handshake toneset, you can wait for the handshake process to complete before sending a signal of a specific form on the handshake toneset to avoid signal interference.
  • Step 925 Determine whether the TU-R can detect the handshake signal before timeout.
  • step 930 may be performed.
  • step 935 may be performed.
  • Step 930 wait for the handshake process to complete.
  • TU-R can determine that there is a handshake protocol signal that is being interacted with in the handshake toneset. After the handshake process is completed, a specific form of signal can be sent on the handshake toneset to avoid signal interference.
  • the TU-R can wait for the completion of the handshake process and then proceed to step 940.
  • the TU-R listens to the handshake toneset and determines whether there are other handshake protocol signals being exchanged in the handshake toneset before timeout.
  • step 935 the TU-R sends a specific signal in the handshake toneset.
  • the TU-R can send an uplink registration information request signal in the handshake toneset if it fails to detect the handshake protocol signal being exchanged in the handshake toneset before timeout.
  • the uplink registration information request signal sent by the TU-R in the handshake toneset may be an R-TONES-REQ signal in the handshake channel. It can also be other signals, for example, energy signals carried within a certain time or frequency band or a differentially encoded binary phase shift keying (DPSK) modulation sequence.
  • DPSK differentially encoded binary phase shift keying
  • the R-TONES-REQ signal in the handshake toneset in the embodiments of the present application may be used to indicate a signal that triggers the TU-O to send an uplink registration window request (to trigger the TU-O to enter the P2MP working mode), and may also be used to indicate that the TU-O is triggered Signal to enter P2P working mode. This application does not specifically limit this.
  • Step 940 The TU-R listens to the first channel and the handshake toneset.
  • TU-R can listen to the first channel and handshake toneset after sending a signal of a specific form in the handshake channel.
  • Step 945 Determine whether the TU-R can detect the uplink registration window indication signal before timeout.
  • the TU-R can detect the uplink registration window indication signal sent by the network device (for example, TU-O in Figure 8) before timeout, it can be understood that TU-O can also support the P2MP working mode, and the TU-R can Perform steps 950-955.
  • the TU-R may detect the uplink registration window indication signal in the handshake toneset, and may also listen to the uplink registration window indication signal in the first channel, which is not specifically limited in this embodiment of the present application.
  • the TU-R does not detect the uplink registration window indication signal before the timeout, it can be understood that the TU-O does not support the P2MP working mode (supports the P2P working mode), and the TU-R can perform steps 965-975.
  • Step 950 The TU-R sends a registration message to terminate the handshake protocol interaction.
  • the TU-R can detect the uplink registration window indication signal sent by the TU-O in FIG. 8 before timeout, it can send registration information at the position of the uplink registration window designated by the TU-O in FIG. 8. At the same time, the TU-R can terminate the handshake interaction.
  • the registration information sent by the TU-R at the designated registration window position may include, but is not limited to, information such as an ID (for example, a MAC address) uniquely identified by the TU-R, and a CRC.
  • Step 955 Determine whether the TU-R is successfully registered.
  • the TU-R After the TU-R sends the registration information at the position of the uplink registration window designated by the TU-O in FIG. 8, it can determine whether the response message sent by the TU-O can be correctly received.
  • step 960 may be performed.
  • step 920 may be performed again.
  • step 960 the TU-R executes the subsequent interaction according to the TU-O and enters the show time.
  • the TU-R can obtain the ID assigned by the TU-O in FIG. 8 and can enter the subsequent initialization process according to the TU-O's indicated or predefined mode, for example, the handshake protocol process. And you can enter show time after initialization.
  • show time can be understood as that the TU-O and TU-R have completed the initialization process and can start sending data on the bearer channel.
  • step 965 the counter is incremented by one.
  • the timeout counter may be incremented by one.
  • Step 970 Determine that the counter exceeds a threshold.
  • the TU-R may perform step 920 again.
  • the TU-R may not support In P2MP mode, the TU-R can perform step 975.
  • Step 975 the TU-R performs a P2P-based handshake interaction.
  • TU-R can send a handshake signal (for example, R-TONES-REQ signal) to TU-O after the counter has not received the uplink registration window indication signal sent by TU-O after exceeding the threshold, and can enter P2P Operating mode. And can continue to complete the subsequent handshake interaction protocol.
  • a handshake signal for example, R-TONES-REQ signal
  • the terminal device can first listen for the registration window indication information sent by the network device. If the window indication information is not intercepted, The terminal device sends a specific implementation of the R-TONES-REQ signal in the handshake toneset.
  • the terminal device sends a specific implementation of the R-TONES-REQ signal in the handshake toneset.
  • FIG. 10 is a schematic diagram of a work flow of another possible terminal device in step 310 in FIG. 3.
  • the method in FIG. 10 may include steps 1010-1095. Steps 1010-1095 are described in detail below.
  • terminal device in FIG. 10 may correspond to the TU-R 254 shown in FIG. 2, and the following uses the working process of the TU-R as an example for detailed description.
  • a channel different from the handshake toneset is referred to as a first channel.
  • Step 1010 Determine whether the TU-R supports the P2MP working mode.
  • the TU-R After the TU-R is powered on, it can determine whether the TU-R supports the P2MP working mode. If the TU-R does not support the P2MP working mode (supports the P2P working mode), step 1015 may be performed. If the TU-R supports the P2MP working mode, go to step 1020.
  • step 1015 the TU-R enters the P2P working mode.
  • the TU-R can perform handshake protocol interaction based on the P2P working mode when it is determined that the P2MP working mode is not supported (supporting the P2P working mode).
  • Step 1020 Determine whether the TU-R can detect the uplink registration window indication signal before the timeout.
  • the TU-R can detect the uplink registration window indication signal sent by the network device (for example, TU-O in Figure 8) before timeout, it can be understood that TU-O can also support the P2MP working mode, and the TU-R can Go to steps 1025-1030.
  • the TU-R does not detect the uplink registration window indication signal before timeout, it can be understood that the TU-O does not support the P2MP working mode (supports the P2P working mode), and the TU-R may perform steps 1040-1045.
  • Step 1025 The TU-R sends a registration message to terminate the handshake interaction.
  • the TU-R can detect the uplink registration window indication signal sent by the TU-O in FIG. 8 before timeout, it can send registration information at the position of the uplink registration window designated by the TU-O in FIG. 8. At the same time, the TU-R can terminate the handshake interaction.
  • the registration information sent by the TU-R at the designated registration window position may include, but is not limited to, information such as an ID (for example, a MAC address) uniquely identified by the TU-R, and a CRC.
  • Step 1030 Determine whether the TU-R is successfully registered.
  • the TU-R After the TU-R sends the registration information at the position of the uplink registration window designated by the TU-O in FIG. 8, it can determine whether the response message sent by the TU-O can be correctly received.
  • step 1035 may be performed.
  • step 1020 may be performed again.
  • step 1035 the TU-R executes the subsequent interaction according to the TU-O and enters the show time.
  • the TU-R can obtain the ID assigned by the TU-O in FIG. 8 and can enter the subsequent initialization process according to the TU-O's indicated or predefined mode, for example, the handshake protocol process. And you can enter show time after initialization.
  • show time can be understood as that the TU-O and TU-R have completed the initialization process and can start sending data on the bearer channel.
  • Step 1040 The TU-R listens to the downlink handshake and toneset.
  • TU-R can judge the support of P2MP working mode, it can first listen to the handshake channel to see if there are other handshake protocol signals in the handshake channel.
  • the TU-R may first listen to whether there are other handshake protocol signals being interacted in the handshake channel. If there is a handshake protocol signal that is being interacted in the handshake channel, you can wait for the handshake process to complete before sending a signal of a specific form on the handshake channel to avoid signal interference.
  • Step 1045 Determine whether the TU-R can detect the handshake protocol signal before timeout.
  • step 1050 can be performed.
  • step 1055 may be performed.
  • Step 1050 wait for the handshake process to complete.
  • TU-R can judge that there is a handshake protocol signal that is being interacted in the handshake channel. After the handshake process is completed, it can send a signal of a specific form on the handshake channel to avoid signal interference.
  • the TU-R may continue to execute step 1040.
  • the TU-R listens to the downlink handshake channel and determines whether there are other handshake protocol signals being interacted in the handshake channel before the timeout.
  • step 1055 the TU-R sends a specific signal in the handshake tonetone channel.
  • TU-R can send an uplink registration information request signal in the handshake channel if it fails to detect the handshake protocol signal that is being interacted in the handshake channel before timeout.
  • the uplink registration information request signal sent by the TU-R in the handshake channel may be an R-TONES-REQ signal in the handshake channel. It can also be other signals, for example, energy signals carried within a certain time or frequency band or a differentially encoded binary phase shift keying (DPSK) modulation sequence.
  • DPSK differentially encoded binary phase shift keying
  • step 1060 the TU-R listens to the first channel and the handshake toneset.
  • TU-R can listen to the first channel and handshake toneset after sending a signal of a specific form in the handshake channel.
  • Step 1065 Determine whether the TU-R can detect the uplink registration window indication signal before timeout.
  • the TU-R can detect the uplink registration window indication signal sent by a network device (for example, TU-O in Figure 8) in the first channel before the timeout, it can be understood that TU-O can also support the P2MP working mode.
  • the TU-R may perform steps 1070 to 1075.
  • the TU-R does not detect the uplink registration window indication signal in the first channel before the timeout, it can be understood that the TU-O does not support the P2MP working mode (supports the P2P working mode). .
  • Step 1070 The TU-R sends a registration message to terminate the handshake interaction.
  • the TU-R can detect the uplink registration window indication signal sent by the TU-O in FIG. 8 before timeout, it can send registration information at the position of the uplink registration window designated by the TU-O in FIG. 8. At the same time, the TU-R can terminate the handshake interaction.
  • the registration information sent by the TU-R at the designated registration window position may include, but is not limited to, information such as an ID (for example, a MAC address) uniquely identified by the TU-R, and a CRC.
  • Step 1075 Determine whether the TU-R is successfully registered.
  • the TU-R After the TU-R sends the registration information at the position of the uplink registration window designated by the TU-O in FIG. 8, it can determine whether the response message sent by the TU-O can be correctly received.
  • step 1080 may be performed.
  • step 1040 can be performed again.
  • step 1080 the TU-R executes the subsequent interaction according to the TU-O and enters the show time.
  • the TU-R can obtain the ID assigned by the TU-O in FIG. 8 and can enter the subsequent initialization process according to the TU-O's indicated or predefined mode, for example, the handshake protocol process. And you can enter show time after initialization.
  • step 1085 the counter is incremented by one.
  • the timeout counter may be incremented by one.
  • Step 1090 Determine whether the counter exceeds a threshold.
  • the TU-R may perform step 1040 again.
  • the TU-R may not support In P2MP working mode, the TU-R can perform step 1095.
  • step 1095 the TU-R performs a P2P-based handshake interaction.
  • TU-R can send a handshake signal (for example, R-TONES-REQ signal) to TU-O after the counter has not received the uplink registration window indication signal sent by TU-O after exceeding the threshold, and can enter P2P Operating mode.
  • a handshake signal for example, R-TONES-REQ signal
  • the terminal device provided in FIG. 10 may be based on FIG. 9, and may first listen for the registration window indication information sent by the network device. If the window indication information is heard, the new user may go online to register directly, thereby simplifying the new user. Registration process for random access.
  • the indication signal may also be a signal with the same frequency band as the R-TONES-REQ signal in the existing handshake toneset, but with a different form (for example, an uplink registration window request signal) network
  • the device may also receive an uplink registration window request signal sent by the terminal device in the handshake and toneset of the first port.
  • the uplink registration window request signal may be used to indicate that the terminal device performs a P2MP working mode.
  • FIG. 11 is a schematic diagram of a work flow of another possible network device in step 310 in FIG. 3.
  • the method in FIG. 11 may include steps 1110-1190. Steps 1110-1190 are described in detail below.
  • the network device in FIG. 11 may correspond to the TU-O 234 shown in FIG. 2, and the following uses the working process of the TU-O as an example for detailed description.
  • a channel different from the handshake toneset is referred to as a first channel.
  • the TU-O detects an R-TONE-REQ signal or a registration window request signal.
  • TU-O can listen to the R-TONE-REQ signal or registration window request signal sent by TU-R in handshake and toneset.
  • the TU-O can detect the R-TONE-REQ signal sent by the TU-R in the handshake toneset, it can be used to indicate the P2P working mode of the TU-R.
  • the TU-O can detect the registration window request signal sent by the TU-R in the handshake and toneset, it can be used to indicate the working mode of the TU-R for P2MP.
  • step 1120 whether the TU-O supports the P2MP working mode and whether a registration window request signal can be detected.
  • the TU-O may perform steps 1130-1140.
  • the TU-O may perform steps 1150-1170.
  • Step 1130 whether the TU-O supports the P2P working mode and whether the R-TONE-REQ signal can be detected.
  • the TU-O can perform step 1140.
  • the TU-O may perform step 1110 again.
  • step 1140 the TU-O enters the P2P working mode and continues to complete the handshake interaction.
  • TU-O After receiving the R-TONE-REQ signal sent by TU-R in the handshake toneset, TU-O can enter the P2P working mode and can continue to complete the subsequent handshake interaction protocol.
  • step 1150 the TU-O sends a registration window indication signal.
  • the TU-O can support the P2MP working mode, and after detecting the registration window request signal sent by the TU-R in the handshake toneset, the TU-O can send a registration window indication signal.
  • step 1160 it is determined whether TU-O can detect the ID of the TU-R.
  • the TU-O After sending the C-IND signal, the TU-O can determine whether it can detect the registration information sent by the TU-R.
  • the registration information may include the unique identification ID of the TU-R.
  • the ID of the TU-R may be, for example, a media access control (MAC) layer address.
  • MAC media access control
  • the TU-O can detect the registration information sent by the TU-R within the indicated registration window, the registration information includes the ID of the TU-R, and the TU-O can perform step 1180.
  • the TU-O may perform step 1110 again.
  • Step 1180 the TU-O sends a response message carrying the ID.
  • the TU-O can detect the uplink registration information sent by the TU-R within the indicated registration window, and can respond to the correctly resolved uplink registration information.
  • step 1190 TU-O designates a newly registered user to complete the handshake process, and performs handshake and toneset detection.
  • TU-O After entering the P2MP working mode, TU-O can assign an ID to the TU-R that has been successfully registered.
  • the TU-O may specify that the TU-R enters a subsequent initialization process, for example, a handshake protocol process.
  • the implementation manner of the terminal device sending the registration window request signal in the embodiment of the present application is the same there are two ways to achieve this.
  • the terminal device may send an R-TONE-REQ signal or a registration window request signal in the handshake toneset.
  • the terminal device may first listen to whether there is registration window indication information sent by the network device, and if not, the terminal device sends an R-TONE-REQ signal or a registration window request signal in a handshake toneset.
  • the terminal device can first listen to the registration window indication information sent by the network device. Specific implementation of sending an R-TONE-REQ signal or a registration window request signal.
  • the example in FIG. 12 is only for helping those skilled in the art to understand the embodiments of the present application, and is not intended to limit the embodiments of the application to the specific values or specific scenarios shown. Those skilled in the art can obviously make various equivalent modifications or changes according to the example of FIG. 12 given in the text, and such modifications and changes also fall within the scope of the embodiments of the present application.
  • FIG. 12 is a schematic diagram of a work flow of another possible terminal device in step 310 in FIG. 3.
  • the method in FIG. 12 may include steps 1210-1265. Steps 1210-1265 are described in detail below.
  • terminal device in FIG. 12 may correspond to the TU-R 236 shown in FIG. 2.
  • the following uses the working process of the TU-R as an example for detailed description.
  • a channel different from the handshake toneset is referred to as a first channel.
  • Step 1210 The TU-R detects the registration window indication information sent by the TU-O.
  • Step 1215 Determine whether the TU-R detects the registration window indication information before timeout.
  • the TU-R can detect the registration window indication information sent by the TU-O before the timeout, the TU-R can perform steps 1220-1225.
  • the TU-R may perform steps 1235-1245.
  • step 1220 the TU-R sends a TU-R registration ID to the TU-O.
  • the TU-R may detect the registration window indication information sent by the TU-O before the timeout.
  • the TU-R may send the registration information to the TU-O, and the registration information may include the ID of the TU-R.
  • the TU-R ID can be used to indicate the MAC address of the TU-R.
  • Step 1225 Determine whether the TU-R is successfully registered.
  • the TU-R After the TU-R sends the registration information at the position of the uplink registration window designated by the TU-O in FIG. 11, it can determine whether the response message sent by the TU-O can be correctly received.
  • step 1230 may be performed.
  • step 1210 can be performed again.
  • step 1230 the TU-R executes the subsequent interaction according to the TU-O and enters the show time.
  • the TU-R can obtain the ID assigned by the TU-O in FIG. 11 and can enter the subsequent initialization process according to the TU-O indicated or predefined mode, for example, the handshake protocol process. And you can enter show time after initialization.
  • step 1235 the counter is incremented to determine whether the counter exceeds a threshold.
  • the timeout counter may be incremented by one.
  • the TU-O may not support the P2MP working mode, and the TU-R may perform step 1240.
  • the TU-R may perform step 1255.
  • step 1240 the TU-R sends an R-TONE-REQ signal and enters the P2P working mode.
  • the TU-O may not support the P2MP working mode.
  • the TU-R can send an R-TONE-REQ signal to the TU-O. This signal can be used to indicate that the TU-R enters the P2P working mode. .
  • Step 1245 Determine whether the TU-R handshake has failed.
  • TU-R After sending the R-TONE-REQ signal to TU-O, TU-R can enter the P2P working mode and continue to complete the subsequent handshake interaction protocol.
  • the TU-R may perform step 1250.
  • the TU-R may perform step 1210 again.
  • step 1250 the TU-R performs initialization after the handshake.
  • TU-R can enter the initialization phase after a successful handshake.
  • step 1255 the TU-R detects an existing handshake.
  • the TU-R can detect the existing handshake.
  • step 1260 it is determined whether the TU-R exits the handshake detection before timeout.
  • the TU-R can perform step 1265.
  • the TU-R may perform step 1255 again.
  • Step 1265 the TU-R sends an uplink registration window request signal (for example, a registration window request signal).
  • an uplink registration window request signal for example, a registration window request signal
  • the TU-R may continue to perform step 1210, and may continue to detect the registration window indication information sent by the TU-O.
  • the TU-R may not need to first detect whether the TU-O sends registration window indication information in step 1210, and may directly send the registration window indication information.
  • the uplink access method provided by the embodiment of the present invention is described in detail above with reference to FIG. 1 to FIG. 12.
  • the device embodiment of the present application will be described in detail below with reference to FIGS. 13 to 16. It should be understood that the description of the method embodiment and the description of the device embodiment correspond to each other. Therefore, for the parts that are not described in detail, reference may be made to the foregoing method embodiment.
  • FIG. 13 shows a schematic block diagram of a network device 1300 according to an embodiment of the present application.
  • Each module in the network device 1300 is configured to perform each action or process performed by the network device in the foregoing method.
  • the description can refer to the description above.
  • FIG. 13 is a schematic block diagram of a network device 1300 according to an embodiment of the present application.
  • the network device 1300 may include:
  • a first receiving module 1310 configured to receive first instruction information sent by a terminal device when going online;
  • the sending module 1320 is configured to send uplink registration window indication information in the first port according to the first indication information.
  • the first receiving module 1310 is specifically configured to: receive, in a first channel of the first port, first indication information sent by the terminal device, and the first indication information It is a signal different from the frequency band of the second channel.
  • the first receiving module 1310 is further specifically configured to: receive, in the second channel of the first port, second instruction information sent by the terminal device, and the first The two indication information are signals of the same frequency band as the second channel.
  • the sending module 1320 specifically uses Yu: sending the uplink registration window indication information in a first channel of the first port according to the first indication information.
  • the sending module 1320 is further configured to: The second channel of the first port performs the handshake protocol flow.
  • FIG. 14 shows a schematic block diagram of a terminal device 1400 according to an embodiment of the present application.
  • Each module in the terminal device 1400 is used to perform each action or process performed by a network device in the foregoing method.
  • the description can refer to the description above.
  • FIG. 14 is a schematic block diagram of a terminal device 1400 according to an embodiment of the present application.
  • the terminal device 1400 may include:
  • a first sending module 1410 configured to send instruction information to a network device on a first port when going online;
  • the first receiving module 1420 is configured to receive, in the second port, uplink registration window indication information sent by the network device.
  • the first instruction information is used to trigger the network device to send uplink registration window instruction information on the first port, and the uplink registration window instruction information is used to instruct the terminal device to send uplink registration information at the indicated registration window position.
  • the second port corresponds to a first port on which the network device receives the indication information.
  • the first sending module 1410 is specifically configured to: the terminal device sends first indication information to the network device in a first channel of the second port, and the first An indication information is a signal different from the frequency band of the second channel.
  • the first sending module 1410 is specifically configured to: the terminal device sends second instruction information to the network device in a second channel of the second port, and the first The two indication information are signals of the same frequency band as the second channel.
  • the terminal device 1400 further includes: a processing module 1430,
  • the processing module 1430 is configured to: when the terminal device detects an existing handshake protocol signal on the second channel, the terminal device waits for the handshake protocol process to be completed.
  • the terminal device further includes: a second sending module 1440,
  • the second sending module 1440 is specifically configured to: in a case where the uplink port registration window indication information is not received on the second port before the timeout, the terminal device sends a The network device sends the second instruction information.
  • the terminal device 1400 further includes: a second receiving module 1450,
  • the second receiving module 1450 is specifically configured to: in a case where the uplink registration window indication information is received in the first channel of the second port, the terminal device sends the indicated registration window position to the network device. registration message.
  • FIG. 15 is a schematic block diagram of a network device 1500 according to an embodiment of the present application.
  • the network device 1500 may include a processor 1501, a receiver 1502, a transmitter 1503, and a memory 1504.
  • the processor 1501 may be communicatively connected with the receiver 1502 and the transmitter 1503.
  • the memory 1504 can be used to store program code and data of the network device. Therefore, the memory 1504 may be a storage unit inside the processor 1501, or an external storage unit independent of the processor 1501, or may include a storage unit inside the processor 1501 and an external storage unit independent of the processor 1501. component.
  • the IoT platform 1500 may further include a bus 1505.
  • the receiver 1502, the transmitter 1503, and the memory 1504 can be connected to the processor 1501 through the bus 1505;
  • the bus 1505 can be a peripheral component interconnect (PCI) bus or an extended industry standard structure (extended industry standard structure) architecture, EISA) bus, etc.
  • the bus 1505 can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is used in FIG. 15, but it does not mean that there is only one bus or one type of bus.
  • the processor 1501 may be, for example, a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate Array (field programmable array, FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logical blocks, modules, and circuits described in connection with the present disclosure.
  • the processor may also be a combination that implements computing functions, such as a combination including one or more microprocessors, a combination of a DSP and a microprocessor, and so on.
  • the receiver 1502 and the transmitter 1503 may be circuits including the antenna and the transmitter chain and the receiver chain described above, and the two may be independent circuits or the same circuit.
  • the receiver 1502 is configured to receive instruction information sent by the terminal device when it is online.
  • the transmitter 1503 performs the following operations by using the processor 1501: configured to send the uplink registration window instruction information in the first port according to the instruction information.
  • the receiver 1502 is specifically configured to receive, in a first channel of the first port, first indication information sent by the terminal device, where the first indication information is the same as the second indication information. Channels with different frequency bands.
  • the receiver 1502 is further specifically configured to: receive, in the second channel of the first port, second instruction information sent by the terminal device, where the second instruction information is A signal having the same frequency band as the second channel.
  • the transmitter 1503 specifically uses Yu: sending the uplink registration window indication information in a first channel of the first port according to the first indication information.
  • the transmitter 1503 when the second information is a signal having the same shape as the R-TONES-REQ signal in the existing handshake protocol of the second channel, the transmitter 1503 is further configured to: The second channel of the first port performs the handshake protocol flow.
  • FIG. 16 is a schematic block diagram of a terminal device 1600 according to an embodiment of the present application.
  • the terminal device 1600 may include a processor 1601, a receiver 1602, a transmitter 1603, and a memory 1604.
  • the processor 1601 may be communicatively connected with the receiver 1602 and the transmitter 1603.
  • the memory 1604 may be used to store program code and data of the terminal device. Therefore, the memory 1604 may be a storage unit inside the processor 1601, or an external storage unit independent of the processor 1601, or may include a storage unit inside the processor 1601 and an external storage unit independent of the processor 1601. component.
  • the IoT platform 1600 may further include a bus 1605.
  • the receiver 1602, the transmitter 1603, and the memory 1604 can be connected to the processor 1601 through a bus 1605;
  • the bus 1605 can be a peripheral component interconnect (PCI) bus or an extended industry standard structure (extended industry standard) architecture, EISA) bus and so on.
  • PCI peripheral component interconnect
  • EISA extended industry standard structure
  • the bus 1605 can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only a thick line is used in FIG. 16, but it does not mean that there is only one bus or one type of bus.
  • the processor 1601 may be, for example, a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate Array (field programmable array, FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logical blocks, modules, and circuits described in connection with the present disclosure.
  • the processor may also be a combination that implements computing functions, such as a combination including one or more microprocessors, a combination of a DSP and a microprocessor, and so on.
  • the receiver 1602 and the transmitter 1603 may be circuits including the antenna and the transmitter chain and the receiver chain described above, and the two may be independent circuits or the same circuit.
  • the sender 1603 is configured to: send the instruction information to the network device on the second port when going online;
  • the receiver 1602 is configured to receive, in the second port, uplink registration window indication information sent by the network device.
  • the first instruction information is used to trigger the network device to send uplink registration window instruction information on the first port, and the uplink registration window instruction information is used to instruct the terminal device to send uplink registration information at the indicated registration window position.
  • the second port corresponds to a first port on which the network device receives the indication information.
  • the transmitter 1603 is specifically configured to: the terminal device sends first instruction information to the network device in a first channel of the second port, and the first instruction The information is a signal different from the frequency band of the second channel.
  • the transmitter 1603 is specifically configured to: the terminal device sends second instruction information to the network device in a second channel of the second port, and the second instruction The information is a signal having the same frequency band as the second channel.
  • the processor 1601 is configured to: when the terminal device listens to an existing handshake protocol signal on the second channel, the terminal device waits for the handshake protocol process to complete.
  • the transmitter 1603 is further specifically configured to: in a case where the uplink registration window indication information is not received on the second port before timeout, the terminal device is in the Sending the second instruction information to the network device in a second channel of a second port.
  • the transmitter 1603 is further specifically configured to: when receiving the uplink registration window indication information in the first channel of the second port, the terminal device indicates Sending registration information to the network device at the registration window position.
  • An embodiment of the present application further provides a chip, which includes a memory, a processor, and a transceiver, where the memory is used to store a program; the processor is used to execute a program stored in the memory, and when the program is executed, The processor executes the method described in any one of the possible implementation manners of the network device.
  • An embodiment of the present application further provides a chip, which includes a memory, a processor, and a transceiver, where the memory is used to store a program; the processor is used to execute a program stored in the memory, and when the program is executed, The processor executes the method described in any one of the possible implementation manners of the terminal device.
  • An embodiment of the present application further provides a computer-readable storage medium including a computer program, and when the computer program is run on a computer, the computer is caused to execute the method described in steps 310-320 and the like.
  • the embodiment of the present application further provides a computer program product, and when the computer program product runs on a computer, the computer is caused to execute the method described in steps 310-320 and the like.
  • An embodiment of the present application further provides a system, including the foregoing terminal device and / or the foregoing network device.
  • various aspects or features of the present application may be implemented as a method, apparatus, or article of manufacture using standard programming and / or engineering techniques.
  • article of manufacture encompasses a computer program accessible from any computer-readable device, carrier, or medium.
  • computer-readable media may include, but are not limited to: magnetic storage devices (eg, hard disks, floppy disks, or magnetic tapes, etc.), optical disks (eg, compact discs (CD), digital versatile discs (DVD) Etc.), smart cards and flash memory devices (for example, erasable programmable read-only memory (EPROM), cards, sticks or key drives, etc.).
  • various storage media described herein may represent one or more devices and / or other machine-readable media used to store information.
  • machine-readable medium may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instruction (s) and / or data.
  • the disclosed systems, devices, and methods may be implemented in other ways.
  • the device embodiments described above are only schematic.
  • the division of the unit is only a logical function division.
  • multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, which may be electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, may be located in one place, or may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objective of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each of the units may exist separately physically, or two or more units may be integrated into one unit.
  • the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium.
  • the technical solution of this application is essentially a part that contributes to the existing technology or a part of the technical solution can be embodied in the form of a software product.
  • the computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in the embodiments of the present application.
  • the aforementioned storage media include: U disks, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks or compact discs and other media that can store program codes .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请提供了一种上行接入的方法、设备，该方法包括：网络设备接收终端设备在上线时发送的指示信息，所述指示信息用于触发所述网络设备在第一端口中发送上行注册窗口指示信息，所述上行注册窗口指示信息用于指示所述终端设备在指示的注册窗口位置发送上行注册信息；所述网络设备根据所述指示信息，在所述第一端口中发送所述上行注册窗口指示信息。本申请实施例提供的技术方案可以在P2MP的工作模式下，避免网络设备周期性的指示注册窗口，从而可以节约资源开销以及节省耗电量。

Description

一种上行接入的方法、设备 技术领域
本申请涉及通信领域，并且更具体地，涉及一种上行接入的方法、设备。
背景技术
以无源光纤网络(passive optical network，PON)为代表的光纤入户(fiber to the home，FTTH)中，光网络单元(optical network unit，ONU)可以位于用户家中，可以提供更大的带宽以及更高的接入网传输速率。但是，FTTH在投资成本、布放、运维、稳定性等方面都存在难以克服的限制。
为了节约FTTH的建设成本，国际电信联盟(international telecommunication union，ITU)成立了G.fast项目来研究光纤到分线点(fiber to the distribution point，FTTdp)场景下，可以利用数字用户线(digital subscriber line，DSL)等铜线接入技术在投资、运维等方面存在明显的优势，使用大量铺设的铜缆电话线来提供ONU与最终用户之间的更高速率的互联网接入。为了给用户提供更高的速率，ITU通过G.MGfast项目来研究支持铜线距离更短的应用场景，为了降低设备成本，G.MGfast系统可以支持点到多点(point-to-muiti-point，P2MP)。
现有技术中在支持点到多点P2MP系统中，网络设备周期性向用户发送上行随机接入的指示信号，新上线的用户可以在指示的随机接入窗口内发送随机接入的信号，以便于新用户进行上线注册。但是，现有技术中网络设备周期性向用户发送上行随机接入的指示信号，造成不必要的资源开销。
因此，如何避免网络设备周期性向用户指示上行随机接入的指示信号造成的资源浪费称为亟需要解决的问题。
发明内容
本申请提供一种上行接入的方法、设备，可以在P2MP的工作模式下，避免网络设备周期性的指示注册窗口，从而可以节约资源开销以及节省耗电量。
第一方面，提供了一种上行接入的方法，该方法包括：网络设备接收终端设备在上线时发送的指示信息；所述网络设备根据所述指示信息，在在所述第一端口发送上行注册窗口指示信息。
应理解，指示信息用于触发所述网络设备在第一端口发送上行注册窗口指示信息，所述上行注册窗口指示信息用于指示所述终端设备在指示的注册窗口位置发送上行注册信息。
本申请实施例中网络设备可以将用户数据通过双绞线(例如，电话线)分发至用户设备。作为一个示例，该网络设备可以是TU-O。该TU-O可以将用户数据通过双绞线(例如，电话线)分发至用户设备，还可以接收终端设备侧发送的数据。
应理解，本申请实施例对网络设备TU-O不做具体限定。作为一个示例，在G.fast项目中，该网络设备可以是FTU-O。作为另一个示例，在G.MGfast项目中，该网络设备可以是MTU-O。
本申请实施例中的终端设备可以是用户或企业中的收发单元，可以接收网络设备通过铜缆双绞线发送的音频信号(模拟信号)，还可以将转换之后的模拟信号通过双绞线发送至网络设备侧。作为一个示例，该终端设备可以是TU-R。
应理解，本申请实施例对终端设备TU-R不做具体限定。作为一个示例，在G.fast项目中，该网络设备可以是FTU-R。作为另一个示例，在G.MGfast项目中，该网络设备可以是MTU-R。
本申请实施例中指示信息可以是触发网络设备发送注册窗口指示信息的一种特定信号，本申请实施例对终端设备在上线时发送的指示信息的频带和信号形态不做具体限定。作为一个示例，该指示信号可以是与现有的handshake toneset中的R-TONES-REQ信号的频带和形态相同的信号。作为另一个示例，该指示信号还可以是与现有的handshake toneset中的R-TONES-REQ信号的频带相同，但形态不相同的信号(例如，上行注册窗口请求信号)。作为另一个示例，该指示信号还可以是与现有的handshake toneset中的R-TONES-REQ信号的频带不相同的其他信号(例如，注册窗口请求信号)。
具体的，该指示信息还可以是一个在一定时域和频域上承载的伪噪声(pseudo noise，PN)序列或ZC(zadoff chu)序列。作为另一个示例，该指示信息还可以是在固定频段固定时间的有一定能量的信号。
应理解，不同形态和频带的指示信息，终端设备可以在不同的通道上发送。网络设备对应的可以在不同的通道中接收到该指示信息。此时，通道可以理解为网络设备侧内部的接收处理通道。
本申请实施例中网络设备接收终端设备发送的指示信息的具体实现方式有多种，本申请对此不做具体限定。作为一个示例，当指示信号还可以是与现有的handshake toneset中的R-TONES-REQ信号的频带不相同的其他信号(例如，上行注册窗口请求信号)时，网络设备可以在第一端口的与handshake toneset不同的通道中接收终端设备发送的指示信息。作为另一个示例，当指示信号可以是与现有的handshake toneset中的R-TONES-REQ信号的频带和形态相同的信号，网络设备可以在第一端口的handshake toneset中接收终端设备发送的指示信息。作为另一个示例，当指示信号还可以是与现有的handshake toneset中的R-TONES-REQ信号的频带相同，但形态不相同的信号(例如，注册窗口请求信号)，网络设备也可以在第一端口的handshake toneset中接收终端设备发送的指示信息。
结合第一方面，在第一方面的某些实现方式中，所述网络设备在所述第一端口的第一通道中接收所述终端设备发送的第一指示信息，所述第一指示信息为与第二通道的频带不同的信号。
结合第一方面，在第一方面的某些实现方式中，所述网络设备在所述第一端口的所述第二通道中接收所述终端设备发送的第二指示信息，所述第二指示信息为与所述第二通道的频带相同的信号。
结合第一方面，在第一方面的某些实现方式中，当所述第二指示信息为与第二通道现有的握手协议中R-TONES-REQ信号频带相同，但信号形态不同的信号时，所述网络设备 根据所述第一指示信息，在所述第一端口的第一通道中发送所述上行注册窗口指示信息。
结合第一方面，在第一方面的某些实现方式中，当所述第二信息为与第二通道现有的握手协议中R-TONES-REQ信号形态相同的信号时，所述方法还包括：所述网络设备在所述第一端口的第二通道进行所述握手协议流程。
第二方面，提供了一种上行接入的方法，该方法包括：终端设备上线时在第二端口向网络设备发送指示信息，所述指示信息用于触发所述网络设备在第一端口发送上行注册窗口指示信息，所述上行注册窗口指示信息用于指示所述终端设备在指示的注册窗口位置发送上行注册信息，所述第二端口与所述网络设备接收所述指示信息的第一端口对应；所述终端设备在所述第二端口中接收所述网络设备发送的上行注册窗口指示信息。
结合第二方面，在第二方面的某些实现方式中，所述终端设备在所述第二端口的第一通道中向所述网络设备发送第一指示信息，所述第一指示信息为与第二通道的频带不同的信号。
结合第二方面，在第二方面的某些实现方式中，所述终端设备在所述第二端口的第二通道中向所述网络设备发送第二指示信息，所述第二指示信息为与所述第二通道的频带相同的信号。
结合第二方面，在第二方面的某些实现方式中，在所述终端设备在所述第二端口的第二通道中向所述网络设备发送第二指示信息之前，所述方法还包括：当终端设备在所述第二通道上侦听到现有的握手协议信号，所述终端设备等待所述握手协议流程完成。
结合第二方面，在第二方面的某些实现方式中，所述方法还包括：所述终端设备在超时之前在所述第二端口未接收到所述上行注册窗口指示信息的情况下，所述终端设备在所述第二端口的第二通道中向所述网络设备发送所述第二指示信息。
可选地，在一些实施例中，如果该终端设备在超时前在所述第二端口未接收到网络设备对该第二指示信息的向响应消息时，该终端设备可以继续尝试在所述第二端口的第一通道中向所述网络设备发送第一指示信息。如此周期循环尝试发送第一指示信息或第二指示信息。
结合第二方面，在第二方面的某些实现方式中，在所述终端设备向网络设备发送指示信息之前，所述方法还包括：所述终端设备在所述第二端口的第一通道中接收到所述上行注册窗口指示信息的情况下，所述终端设备在指示的注册窗口位置向所述网络设备发送注册信息。
第三方面，提供了一种网络设备，包括：第一接收模块、发送模块，
第一接收模块用于：接收终端设备在上线时发送的指示信息；
发送模块用于：根据所述指示信息，在所述第一端口发送上行注册窗口指示信息。
应理解，指示信息用于触发所述网络设备在第一端口发送上行注册窗口指示信息，所述上行注册窗口指示信息用于指示所述终端设备在指示的注册窗口位置发送上行注册信息。
结合第三方面，在第三方面的某些实现方式中，所述第一接收模块具体用于：在所述第一端口的第一通道中接收所述终端设备发送的第一指示信息，所述第一指示信息为与第二通道的频带不同的信号。
结合第三方面，在第三方面的某些实现方式中，所述第一接收模块还具体用于：在所 述第一端口的所述第二通道中接收所述终端设备发送的第二指示信息，所述第二指示信息为与所述第二通道的频带相同的信号。
结合第三方面，在第三方面的某些实现方式中，当所述第二指示信息为与第二通道现有的握手协议中R-TONES-REQ信号频带相同，但信号形态不同的信号时，发送模块具体用于：根据所述第一指示信息，在所述第一端口的第一通道中发送所述上行注册窗口指示信息。
结合第三方面，在第三方面的某些实现方式中，当所述第二信息为与第二通道现有的握手协议中R-TONES-REQ信号形态相同的信号时，所述发送模块还用于：在所述第一端口的第二通道进行所述握手协议流程。
第四方面，提供了一种终端设备，该终端设备包括：第一发送模块、第一接收模块，
所述第一发送模块用于：在上线时向网络设备发送指示信息；
所述第一接收模块用于：在所述第二端口中接收所述网络设备发送的上行注册窗口指示信息。
其中，所述第一指示信息用于触发所述网络设备在第一端口发送上行注册窗口指示信息，所述上行注册窗口指示信息用于指示所述终端设备在指示的注册窗口位置发送上行注册信息。
应理解，所述第二端口与所述网络设备接收所述指示信息的第一端口对应。
结合第四方面，在第四方面的某些实现方式中，所述第一发送模块具体用于：所述终端设备在所述第二端口的第一通道中向所述网络设备发送第一指示信息，所述第一指示信息为与第二通道的频带不同的信号。
结合第四方面，在第四方面的某些实现方式中，所述第一发送模块具体用于：所述终端设备在所述第二端口的第二通道中向所述网络设备发送第二指示信息，所述第二指示信息为与所述第二通道的频带相同的信号。
结合第四方面，在第四方面的某些实现方式中，所述终端设备还包括：处理模块，
该处理模块用于：当终端设备在所述第二通道上侦听到现有的握手协议信号，所述终端设备等待所述握手协议流程完成。
结合第四方面，在第四方面的某些实现方式中，所述终端设备还包括：第二发送模块，
该第二发送模块具体用于：在超时之前在所述第二端口未接收到所述上行注册窗口指示信息的情况下，所述终端设备在所述第二端口的第二通道中向所述网络设备发送所述第二指示信息。
结合第四方面，在第四方面的某些实现方式中，所述终端设备还包括：第二接收模块，
该第二接收模块具体用于：在所述第二端口的第一通道中接收到所述上行注册窗口指示信息的情况下，所述终端设备在指示的注册窗口位置向所述网络设备发送注册信息。
第五方面，提供了一种网络设备，该网络设备包括：存储器、处理器和收发器，
所述存储器用于存储程序；所述处理器用于执行所述存储器中存储的程序，当所述程序被执行时，所述处理器通过所述收发器执行第一方面或第一方面中任意一种可能的实现方式中所述的方法。其中，该处理器可以与收发器通信连接。该存储器可以用于存储该网络设备的程序代码和数据。因此，该存储器可以是处理器内部的存储单元，也可以是与处理器独立的外部存储单元，还可以是包括处理器内部的存储单元和与处理器独立的外部存 储单元的部件。
可选地，该处理器可以是通用处理器，可以通过硬件来实现也可以通过软件来实现。当通过硬件实现时，该处理器可以是逻辑电路、集成电路等；当通过软件来实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现，该存储器可以集成在处理器中，可以位于该处理器之外，独立存在。
当程序被执行时，所述收发器用于：接收终端设备在上线时发送的指示信息；
所述处理器用于执行所述存储器中存储的程序，当所述程序被执行时，所述收发器听过所述处理器执行如下步骤：根据所述指示信息，在所述所述第一端口发送上行注册窗口指示信息。
应理解，指示信息用于触发所述网络设备在第一端口中发送上行注册窗口指示信息，所述上行注册窗口指示信息用于指示所述终端设备在指示的注册窗口位置发送上行注册信息。
结合第五方面，在第五方面的某些实现方式中，所述收发器具体用于：：在所述第一端口的第一通道中接收所述终端设备发送的第一指示信息，所述第一指示信息为与第二通道的频带不同的信号。
结合第五方面，在第五方面的某些实现方式中，所述收发器还具体用于：在所述第一端口的所述第二通道中接收所述终端设备发送的第二指示信息，所述第二指示信息为与所述第二通道的频带相同的信号。
结合第五方面，在第五方面的某些实现方式中，当所述第二指示信息为与第二通道现有的握手协议中R-TONES-REQ信号频带相同，但信号形态不同的信号时，所述收发器具体用于：根据所述第一指示信息，在所述第一端口的第一通道中发送所述上行注册窗口指示信息。
结合第五方面，在第五方面的某些实现方式中，当所述第二信息为与第二通道现有的握手协议中R-TONES-REQ信号形态相同的信号时，所述收发器具体用于：在所述第一端口的第二通道进行所述握手协议流程。
第六方面，提供了一种终端设备，该终端设备包括：存储器、处理器和收发器，
所述存储器用于存储程序；所述处理器用于执行所述存储器中存储的程序，当所述程序被执行时，所述处理器通过所述收发器执行第一方面或第一方面中任意一种可能的实现方式中所述的方法。其中，该处理器可以与收发器通信连接。该存储器可以用于存储该终端设备的程序代码和数据。因此，该存储器可以是处理器内部的存储单元，也可以是与处理器独立的外部存储单元，还可以是包括处理器内部的存储单元和与处理器独立的外部存储单元的部件。
可选地，该处理器可以是通用处理器，可以通过硬件来实现也可以通过软件来实现。当通过硬件实现时，该处理器可以是逻辑电路、集成电路等；当通过软件来实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现，该存储器可以集成在处理器中，可以位于该处理器之外，独立存在。
当程序被执行时，所述收发器用于：在上线时向网络设备发送指示信息；
所述收发器还用于：在所述第二端口中接收所述网络设备发送的上行注册窗口指示信息。
其中，所述指示信息用于触发所述网络设备在第一端口中发送上行注册窗口指示信息，所述上行注册窗口指示信息用于指示所述终端设备在指示的注册窗口位置发送上行注册信息。
应理解，所述第二端口与所述网络设备接收所述指示信息的第一端口对应。
结合第六方面，在第六方面的某些实现方式中，所述收发器具体用于：所述终端设备在所述第二端口的第一通道中向所述网络设备发送第一指示信息，所述第一指示信息为与第二通道的频带不同的信号。
结合第六方面，在第六方面的某些实现方式中，所述收发器具体用于：所述终端设备在所述第二端口的第二通道中向所述网络设备发送第二指示信息，所述第二指示信息为与所述第二通道的频带相同的信号。
结合第六方面，在第六方面的某些实现方式中，所述的处理器用于：当终端设备在所述第二通道上侦听到现有的握手协议信号，所述终端设备等待所述握手协议流程完成。
所述收发器还具体用于：在超时之前在所述第二端口未接收到所述上行注册窗口指示信息的情况下，所述终端设备在所述第二端口的第二通道中向所述网络设备发送所述第二指示信息。
结合第六方面，在第六方面的某些实现方式中，所述收发器还具体用于：在所述第二端口的第一通道中接收到所述上行注册窗口指示信息的情况下，所述终端设备在指示的注册窗口位置向所述网络设备发送注册信息。
第七方面，提供了一种芯片，包括存储器、处理器和收发器，
其中，该处理器可以与收发器通信连接。该存储器可以用于存储该网络设备的程序代码和数据。因此，该存储器可以是处理器内部的存储单元，也可以是与处理器独立的外部存储单元，还可以是包括处理器内部的存储单元和与处理器独立的外部存储单元的部件。
可选地，该处理器可以是通用处理器，可以通过硬件来实现也可以通过软件来实现。当通过硬件实现时，该处理器可以是逻辑电路、集成电路等；当通过软件来实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现，该存储器可以集成在处理器中，可以位于该处理器之外，独立存在。
当程序被执行时，所述收发器通过所述处理器执行第一方面或第一方面中任一种可能的实现方式。
第八方面，提供了一种芯片，包括存储器、处理器和收发器，
其中，该处理器可以与收发器通信连接。该存储器可以用于存储该终端设备的程序代码和数据。因此，该存储器可以是处理器内部的存储单元，也可以是与处理器独立的外部存储单元，还可以是包括处理器内部的存储单元和与处理器独立的外部存储单元的部件。
可选地，该处理器可以是通用处理器，可以通过硬件来实现也可以通过软件来实现。当通过硬件实现时，该处理器可以是逻辑电路、集成电路等；当通过软件来实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现，该存储器可以集成在处理器中，可以位于该处理器之外，独立存在。
当程序被执行时，所述收发器通过所述处理器执行第二方面或第二方面中任一种可能的实现方式。
第九方面，提供了一种计算机可读存储介质，包括计算机程序，当该计算机程序在计 算机上运行时，使得该计算机如执行第一方面或第一方面的任意一种实现方式中所述的方法。
第十方面，提供了一种计算机可读存储介质，包括计算机程序，当该计算机程序在计算机上运行时，使得该计算机执行第二面或第二方面任意一种实现方式中所述的方法。
第十一方面，提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得该计算机执行如第一方面或第一方面任意一种实现方式中所述的方法。
第十二方面，提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得该计算机执行如第二方面或第二方面任意一种实现方式中所述的方法。
第十三方面，提供了一种系统，包括前述的终端设备和网络设备。
附图说明
图1是本申请实施例提供的一种G.MGfast设备的应用场景示意图。
图2是本申请实施例提供的一种G.MGfast的参考模型示意图。
图3是本申请实施例提供的一种上行接入的方法的示意性流程图。
图4是本申请实施例提供的handshake协议的示意性框图。
图5是图3中的步骤310的一种可能的网络设备的工作流程示意图。
图6是图3中的步骤310的一种可能的终端设备的工作流程示意图。
图7是图3中的步骤310的另一种可能的终端设备的工作流程示意图。
图8是图3中的步骤310的另一种可能的网络设备的工作流程示意图。
图9是图3中的步骤310的另一种可能的终端设备的工作流程示意图。
图10是图3中的步骤310的另一种可能的终端设备的工作流程示意图。
图11是图3中的步骤310的另一种可能的网络设备的工作流程示意图。
图12是图3中的步骤310的另一种可能的终端设备的工作流程示意图。
图13是本申请实施例提供的网络设备1300的示意性框图。
图14是本申请实施例提供的终端设备1400的示意性框图。
图15是本申请实施例提供的一种网络设备1500的示意性框图。
图16是本申请实施例提供的一种终端设备1600的示意性框图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
无源光纤网络PON可以是指在局端设备与用户设备之间完全以光纤作为传输介质。PON可以包括：光线路终端(optical line terminal，OLT)、光分配网络(optical distribution network，ODN)、光网络单元ONU等。下面分别对PON中的设备进行详细介绍。
光线路终端OLT：可以是重要的局端设备，可以与前端交换机用网线连接，并转换成光信号。OLT可以为光分配网络ODN提供接口，可以与一个或多个ODN相连，可以为光网络单元ONU所需的接口提供必要的传输方式。
光分配网络ODN：可以是PON设备的光纤网络，可以为OLT与ONU之间提供光传输通道。
光网络单元ONU：可以是光纤接入的终端设备(光纤接入网中光纤终结的设备)， 可以位于用户侧。可以根据ONU在用户侧的位置，可以将光纤接入的方式分为如下几种：光纤入户(fiber to the home，FTTH)、光纤到大楼(fiber to the building，FTTB)、光纤到路边(fiber to the curb，FTTC)、光纤到办公楼(fiber to the office，FTTO)、光纤到小区(fiber to the zone，FTTZ)、光纤到电杆(fiber to the pole，FTTP)等。需要说明，光网络终端(optical network terminal,ONT)也可以当成一个ONU。
以无源光纤网络PON为代表的光纤入户(fiber to the home，FTTH)中，ONU可以位于用户家中，可以提供更大的带宽以及更高的接入网传输速率。但是，FTTH在投资成本、布放、运维、稳定性等方面都存在难以克服的限制。
为了节约FTTH的建设成本，可以将ONU设置在大楼、路边、办公楼、小区、电杆等位置(可以对应上文提及的不同的光纤接入方式，例如，FTTB、FTTC、FTTO、FTTZ、FTTP等)，并可以充分利用大量铺设的铜缆电话线为ONU与最终用户之间的“最后一公里”提供宽带接入服务。
国际电信联盟(international telecommunication union，ITU)成立了G.fast项目来研究光纤到分线点(fiber to the distribution point，FTTdp)场景下，可以利用数字用户线(digital subscriber line，DSL)等铜线接入技术在投资、运维等方面存在明显的优势，使用大量铺设的铜缆电话线来提供ONU与最终用户之间的更高速率的互联网接入。G.fast项目的目标可以是为用户提供高达1Gbit/s的接入速率。
为了给用户提供更高的速率，ITU通过G.MGfast项目来研究支持铜线距离更短的应用场景，为了降低设备成本，G.MGfast系统可以支持点到多点(point-to-muiti-point，P2MP)。G.MGfast系统中，可以通过G.MGfast设备实现将网络数据在铜缆电话线上分发至用户设备，可以为用户设备提供更高速率的互联网接入。
下面结合图1详细描述本申请实施例中G.MGfast设备的应用场景。
图1是本申请实施例提供的一种G.MGfast设备的应用场景示意图。图1所示，该G.MGfast设备的应用场景可以包括：光线路终端OLT110、光分配网络ODN 120，2个分散处理单元DPU(例如，DPU 130、DPU 140)，每个DPU中可以包括光网络单元ONU以及G.MGfast设备，每个DPU下面可以携带2个用户(例如，DPU130下面携带的用户包括：用户136、用户138，DPU 140下面携带的用户包括：用户146、用户148)。
需要说明的是，G.MGfast设备的应用场景中，分散处理单元DPU可以由多个，每个DPU携带的用户数也可以是多个，图1场景中DPU的数量以及用户数量仅仅是作为一个示例，本申请对此不做具体限定。
应理解，图1所示出的应用场景中，DPU130可以是将ONU设置在路边的场景(例如，FTTC技术)，DPU 140可以是将ONU设置在大楼150的场景(例如，FTTB技术)。本申请实施例对G.MGfast设备的具体应用场景不做限定，还可以是上文提及的FTTO、FTTO、FTTZ、FTTP等场景。
下面以DPU 130为例进行详细描述。光线路终端OLT 110作为局端设备，可以通过ODN 120将用户数据通过光纤网络分发至分散处理单元DPU 130。DPU 130内部的ONU以及G.MGfast设备将用户数据在铜线134上分发至用户136中的调制解调器modem(modem也可以理解为用户136家中上网的“猫”，可以负责模拟信号和数字信号之间的转换)，并可以将用户数据在铜线132上分发至用户138中的modem。
下面与DPU 140为例进行详细描述。光线路终端OLT 110作为局端设备，可以通过ODN 120将用户数据通过光纤网络分发至分散处理单元DPU 140。DPU 140内部的ONU以及G.MGfast设备将用户数据在铜线142上分发至大楼中的用户146中的modem，并可以将用户数据在铜线144上分发至用户148中的modem。
当DPU以及用户之间可以支持点到多点P2MP的工作模式(DPU下面可以携带多个用户)，多个用在户之间存在上行接入的问题(由于用户在注册前，处于无序状态，因此，也可以称为随机接入)。需要在用户上线时，进行用户注册以及对应的测距，以便于后续为用户分配上行传输资源。
具体地，下面结合图2对上文描述的分散处理单元DPU130通过铜线将数据分发至用户136的具体参考模型进行详细描述。
图2是本申请实施例提供的一种G.MGfast的参考模型示意图。如图2所示，该G.MGfast的参考模型可以包括：OLT110、ODN 120、DPU 130、端口物理层(port physical layer，PHY)232、收发单元(transceiver unit at the optical network unit，TU-O)234、双绞线(wire pair)240、用户136、PHY 238、远程站点上的收发单元(transceiver unit at the remote site，TU-R)236。
参见图2，对于下行而言，光线路终端OLT 110可以通过光分配网络ODN 120将数据传输至分散处理单元DPU 130。DPU 130中的端口物理层PHY 232可以作为接入网，可以将接收到的数据通过TU-O 234，在双绞线240上分发至用户136家中的调制解调器modem。用户136家中的modem可以通过TU-R 236接收数据，并可以将该数据发送至计算机。
应理解，分散处理单元DPU 130可以作为网络设备，可以将用户数据通过双绞线分发至用户136。TU-O 234和TU-R236可以分别作为DPU 130以及用户136中的收发单元。
本申请实施例中，DPU 130可以有多个端口(也可以理解为包括多个TU-O)，每个端口下面可以携带一个或多个用户136。作为一个示例，如果，DPU 130中的一个端口下面携带一个用户136，该端口可以支持点到点(point-to-point，P2P)协议，DPU 130以及用户136可以工作在P2P工作模式。作为另一个示例，如果DPU 130中的一个端口下面携带多个用户136，该端口可以支持P2MP协议，DPU 130以及用户136可以工作在P2MP工作模式。
应理解，支持P2MP工作模式的终端设备、网络设备同样也可以支持P2P工作模式。具体的有关终端设备以及网络设备是工作在哪种模式下，可以双方进行协商，下面会结合具体的实施例进行详细描述，此处不再赘述。
继续参见图2，对于上行而言，用户136可以在需要上线时，可以通过TU-R 236进行上行随机接入。DPU 130中的TU-O 234可以根据支持的工作模式，可以响应用户136的注册响应，从而完成注册。
下面详细介绍终端设备上行随机接入的过程。
在P2MP的工作模式下，DPU 130内部的TU-O 234(作为网络设备)需要向用户136中的TU-R 236(作为终端设备)发送上行随机接入的窗口指示，终端设备可以在指定的窗口位置发送携带ID的消息，网络设备可以在下行信道中发送携带该ID的响应消息，并进一步鉴权确定冲突，从而完成用户的注册。
现有技术中，在P2MP的工作模式下，网络设备周期性的向网络设备指示随机接入的窗口位置，从而使得终端设备可以在指定的窗口位置发送注册消息。一方面，由于网络设备下面携带的终端设备数目较少，且随机接入的概率较低，因此，网络设备周期性的指示注册窗口会造成资源浪费。另一方面，如果网络设备下面携带的终端设备没有工作，网络设备的发送端需要保持在工作状态，因此，网络设备周期性的指示注册窗口会造成耗电、功耗较大等问题。
本申请实施例提供的一种上行接入的方法可以避免网络设备周期性的指示注册窗口，可以节约资源开销以及节省耗电量。
下面结合图3详细描述本申请实施例提供的一种上行接入的方法进行详细描述。
图3是本申请实施例提供的一种上行接入的方法的示意性流程图。图3所示的方法可以包括步骤310-320，下面分别对步骤310-320进行详细描述。
步骤310，网络设备接收终端设备在上线时发送的指示信息。
本申请实施例中网络设备可以将用户数据通过双绞线(例如，电话线)分发至用户设备。作为一个示例，该网络设备可以是图2所示的TU-O 234。该TU-O 234可以将用户数据通过双绞线(例如，电话线)分发至用户设备，还可以接收终端设备侧发送的数据。
应理解，本申请实施例对网络设备TU-O不做具体限定。作为一个示例，在G.fast项目中，该网络设备可以是FTU-O。作为另一个示例，在G.MGfast项目中，该网络设备可以是MTU-O。
本申请实施例中的终端设备可以是用户或企业中的收发单元，可以接收网络设备通过铜缆双绞线发送的音频信号(模拟信号)，还可以将转换之后的模拟信号通过双绞线发送至网络设备侧。作为一个示例，该终端设备可以是图2所示的TU-R 236。
应理解，本申请实施例对终端设备TU-R不做具体限定。作为一个示例，在G.fast项目中，该网络设备可以是FTU-R。作为另一个示例，在G.MGfast项目中，该网络设备可以是MTU-R。
终端设备可以在需要上线时，可以向网络设备发送指示信息，该指示信息可以用于触发网络设备向终端设备发送注册窗口指示信息。如果该终端设备可以侦听到网络设备发送的注册窗口指示信息，该终端设备可以根据网络设备指示的注册窗口的位置进行上行注册。终端设备可以在注册成功之后，可以进入后续的初始化流程，例如握手(handshake)流程。下面会结合图4对握手(handshake)流程进行详细描述，此处不再赘述。
本申请实施例中第一指示信息可以是触发网络设备发送注册窗口指示信息的一种特定信号，本申请实施例对终端设备在上线时发送的指示信息的频带和信号形态不做具体限定。作为一个示例，该指示信号可以是与现有的握手子载波集handshake toneset中的远端子载波请求R-TONES-REQ信号的频带和形态相同的信号。作为另一个示例，该指示信号还可以是与现有的handshake toneset中的R-TONES-REQ信号的频带相同，但形态不相同的信号(例如，上行注册窗口请求信号)。作为另一个示例，该指示信号还可以是与现有的handshake toneset中的R-TONES-REQ信号的频带不相同的其他信号(例如，注册窗口请求信号)。
具体的，该指示信息可以是一个在一定时域和频域上承载的伪噪声(pseudo noise，PN)序列或扎德奥夫-朱(zadoff chu，ZC)序列。作为另一个示例，该指示信息还可以是 在固定频段固定时间的有一定能量的信号。
应理解，不同形态和频带的指示信息，终端设备可以在不同的通道上发送。网络设备对应的可以在不同的通道中接收到该指示信息。此时，通道可以理解为网络设备侧内部的接收处理通道。
本申请实施例中网络设备接收终端设备发送的第一指示信息的具体实现方式有多种，本申请对此不做具体限定。
作为一个示例，当指示信号还可以是与现有的handshake toneset中的R-TONES-REQ信号的频带不相同的其他信号(例如，上行注册窗口请求信号)时，网络设备可以在第一端口的与handshake toneset不同的通道中接收终端设备发送的上行注册窗口请求信号。作为另一个示例，当指示信号可以是与现有的handshake toneset中的R-TONES-REQ信号的频带和形态相同的信号，网络设备可以在第一端口的handshake toneset中接收终端设备发送的R-TONES-REQ信号。作为另一个示例，当指示信号还可以是与现有的handshake toneset中的R-TONES-REQ信号的频带相同，但形态不相同的信号(例如，注册窗口请求信号)，网络设备也可以在第一端口的handshake toneset中接收终端设备发送的注册窗口请求信号。下面会结合图5至图12进行详细说明，此处不再赘述。
步骤320，网络设备根据指示信息，向终端设备发送上行注册窗口指示信息。
网络设备可以根据接收到的指示信息，可以向终端设备发送上行注册窗口指示信息。终端设备可以在指示的注册窗口位置发送上行注册信息，从而进入P2MP工作模式。
应理解，本申请实施例对网络设备根据向终端设备发送上行注册窗口指示信息的实现方式不做限定。作为一个示例，网络设备可以在第一端口中与handshake toneset不同的通道(可以理解为P2MP下行广播通道)中发送上行注册窗口指示信息。作为一个示例，网络设备还可以在第一端口中的handshake toneset中发送上行注册窗口指示信息。
本申请实施例中，可以在P2MP的工作模式下，避免网络设备周期性的指示注册窗口，从而可以节约资源开销以及节省耗电量。
下面结合图4详细描述本申请实施例中handshake的工作流程。
图4是本申请实施例提供的handshake协议的示意性框图。如图4所示，handshake协议流程可以包括三个阶段：建链410、握手消息交互420、拆链430。
下面以建链410为例进行详细说明handshake交互协议。
TU-R刚开始处于传输静默状态(例如，R-SILENT0信号)，TU-O刚开始也处于传输静默状态(例如，C-SILENT1信号)。TU-R可以通过发送其信号家族中的一个或多个信号来启动程序(例如，R-TONES-REQ信号)，该多个信号的相位每16ms反转一次。当TU-O检测到TU-R发送的R-TONES-REQ信号之后，该TU-O可以通过发送其信号家族中的一个或多个信号进行响应(例如，C-TONES信号)。当TU-R检测到TU-O发送的C-TONES信号之后，该TU-R可以保持50ms到500ms的传输静默状态(例如，R-SILENT1信号)，之后，该TU-R可以只发送其信号家族中的一个信号(例如，R-TONE1信号)。当TU-O检测到TU-R发送的R-TONE1信号之后，该TU-O可以通过在调制载波上发送GALF信号进行响应(例如，C-GALF1信号)。当TU-R检测到TU-O发送的C-TONES信号之后，该TU-R可以通过在调制载波上发送FLAG信号(例如，R-FLAG1信号)。当TU-O检测到TU-R发送的R-FLAG1信号之后，该TU-O可以可以通过在调制载波上发 送GALF信号进行响应(例如，C-FLAG1信号)。当TU-R检测到TU-O发送的C-FLAG1信号之后，该TU-R可以进行第一次数据传输。
步骤310的具体实现方式有多种，可选地，在一些实施例中，当终端设备发送的指示信号是与现有的handshake toneset中的R-TONES-REQ信号的频带不相同的其他信号(例如，上行注册窗口请求信号)时，网络设备可以在第一端口的与handshake toneset不同的通道(可以理解为P2MP通道)中接收终端设备发送的上行注册窗口请求信号。下面会结合图5对网络设备可以在第一端口与handshake toneset不同的通道(可以理解为P2MP通道)中接收终端设备发送的上行注册窗口请求信号的具体实现方式进行详细描述。
可选地，在一些实施例中，在图5的基础上，网络设备还可以在第一端口的handshake toneset中侦听是否有终端设备发送的handshake协议中的R-TONES-REQ信号。如果网络设备可以在第一端口的handshake toneset中接收到终端设备发送的R-TONES-REQ信号，该网络设备可以进入P2P的工作模式。
本申请实施例中，可以同时兼容P2P设备以及P2MP设备。
下面结合图5中具体的例子，更加详细地描述本申请实施例中当终端设备发送的指示信号是与现有的handshake toneset中的R-TONES-REQ信号的频带不相同的其他信号(例如，上行注册窗口请求信号)时，网络设备可以在第一端口的与handshake toneset不同的一个上行通道(也可以理解为P2MP上行通道)中接收终端设备发送的上行注册窗口请求信号的具体实现方式。应注意，图5的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据文所给出的图5的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图5是图3中的步骤310的一种可能的网络设备的工作流程示意图。图5的方法可以包括步骤510-570，下面分别对步骤510-570进行详细描述。
应理解，图5中的网络设备可以对应于图2所示的TU-O 234，下面以TU-O的工作流程为例进行详细说明。
为了便于描述，本申请实施例中将与handshake toneset不同的通道称为第一通道。
步骤510，TU-O同时侦测handshake toneset和第一通道。
TU-O可以在上电之后，可以同时侦听一个端口的handshake toneset以及第一通道。
步骤520，TU-O是否可以在handshake toneset或第一通道侦听到特定信号。
如果TU-O可以在handshake toneset或第一通道中侦听到特定信号，该TU-O可以执行步骤530。如果TU-O没有在handshake toneset或第一通道中侦听到特定信号，该TU-O可以继续执行步骤510，重新对handshake toneset以及第一通道进行侦听。
步骤530，TU-O是否可以在handshake toneset侦听到特定信号。
如果TU-O可以在handshake toneset中侦听到终端设备(例如，上文提及的TU-R)发送的特定信号，例如，图4所示的R-TONES-REQ信号，该TU-O可以进入步骤540。如果TU-O没有在handshake toneset中侦听到终端设备发送的特定信号，该TU-O在第一通道中侦听到终端设备发送的特定信号，例如，上行注册窗口请求信号，该TU-O可以进入步骤550。
步骤540，TU-O进入P2P工作模式。
如果TU-O可以在handshake toneset中侦听到特定信号(例如，图4所示的R-TONES-REQ信号)之后，该TU-O可以进入P2P工作模式，并可以继续完成后续的handshake交互协议。
需要说明的是，如果之后TU-O工作在P2P工作模式，该TU-O不再支持P2MP的工作模式。
步骤550，TU-O在第一通道中发送上行注册窗口指示信号。
如果TU-O可以在第一通道中侦听到TU-R发送的特定信号(例如，上行注册窗口请求信号)之后，该TU-O可以在第一通道中发送上行注册窗口指示信号。该上行注册窗口指示信号可以指示TU-R可以在指定的窗口位置发送上行注册信息。
可选地，TU-O还可以在第一通道中发送上行注册窗口指示信号之前，可以先发送一段训练序列，该训练序列可以用于TU-R的下行信道的同步和训练。
步骤560，判断新用户是否注册成功。
如果TU-O可以在指示的注册窗口内检测到TU-R发送的上行注册信息，并可以响应正确解析的上行注册信息，该TU-O可以完成新用户的注册，并可以进入步骤570，工作在P2MP的工作模式下。
如果TU-O没有在指示的注册窗口内检测到TU-R发送的上行注册信息，那么该TU-O可以进入步骤510，重新对handshake toneset以及第一通道进行侦听。
步骤570，TU-O指定新注册用户完成handshake流程，并进行第一通道侦测。
TU-O可以在进入P2MP工作模式之后，可以对于已经注册成功的TU-R分配一个ID。该TU-O可以指定TU-R进入后续的初始化流程，例如，handshake协议流程。
需要说明的是，如果TU-O已经工作在P2MP工作模式，那么后续该TU-O可以执行步骤550，可以只检测第一通道中是否有TU-R发送的特定信号。并可以按照步骤550-570完成新用户的注册。
本申请实施例提供的网络设备，可以P2MP的工作模式下，避免周期性的指示注册窗口，从而可以节约资源开销以及节省耗电量。同时，该网络设备还可以同时兼容P2P工作模式的设备以及P2MP工作模式的设备。
对应于图5所示的网络设备在第一端口的与handshake toneset不同的通道(可以理解为P2MP通道)中接收终端设备(例如，TU-R)发送的上行注册窗口请求信号，本申请实施例对终端设备发送第一指示信息的实现方式不做具体限定。作为一个示例，终端设备在判断可以支持P2MP的工作模式之后，可以在与handshake toneset不同的通道中发送上行注册窗口请求信号，并可以根据网络设备指示的注册窗口位置发送上行注册信息。作为另一个示例，终端设备可以先侦听是否有网络设备发送的注册窗口指示信息，如果终端设备可以侦听到该窗口指示信息，可以根据注册窗口位置发送上行注册信息。如果终端设备没有侦听到该窗口指示信息，该终端设备可以在与handshake toneset不同的通道中发送上行注册窗口请求信号，并可以根据网络设备指示的注册窗口位置进行上行注册。下面会结合图6-图7对上述两种的具体实现方式进行详细描述，此处不再赘述。
下面结合图6中具体的例子，对应于图5，更加详细地描述本申请实施例中终端设备在判断可以支持P2MP的工作模式之后，当终端设备发送的指示信号是与现有的handshake toneset中的R-TONES-REQ信号的频带不相同的其他信号(例如，上行注册窗口请求信号) 时，终端设备可以在与handshake toneset不同的通道中发送上行注册窗口请求信号的具体实现方式。应注意，图6的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据文所给出的图6的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图6是图3中的步骤310的一种可能的终端设备的工作流程示意图。图6的方法可以包括步骤610-660，下面分别对步骤610-660进行详细描述。
应理解，图6的终端设备可以对应于图2所示的TU-R 236，下面以TU-R的工作流程为例进行详细说明。
为了便于描述，本申请实施例中将与handshake toneset不同的通道称为第一通道。。
步骤610，判断TU-R是否支持P2MP工作模式。
TU-R可以在上电之后，可以判断该TU-R是否支持P2MP工作模式。如果该TU-R不支持P2MP工作模式(支持P2P工作模式)，可以执行步骤615。如果该TU-R支持P2MP工作模式，可以执行步骤620。
步骤615，TU-R进入P2P工作模式。
TU-R可以在判断不支持P2MP工作模式(支持P2P工作模式)的情况下，可以进行基于P2P工作模式的handshake协议交互。
步骤620，TU-R在第一通道中发送特定信号。
如果TU-R支持P2MP工作模式，该TU-R可以在第一通道中发送特定信号。例如，该特定信号可以是上行注册窗口请求信息。
具体的，该特定信号可以是一个在一定时域和频域上承载的PN序列或ZC序列，还可以是一个在固定频段固定时间的有一定能量的信号。
步骤625，TU-R侦听第一通道。
TU-R可以在第一通道中发送特定信号之后，可以侦听第一通道。
步骤630，判断TU-R在超时前是否能侦听到上行注册窗口指示信号。
判断TU-R在超时前是否可以侦听到网络设备(例如，图5中的TU-O)发送的上行注册窗口指示信号。
如果该TU-R可以在超时前侦听到TU-O发送的上行注册窗口指示信号，该TU-R可以执行步骤635-645。
如果该TU-R可以在超时前在第一通道中没有侦听到图5中的TU-O发送的上行注册窗口指示信号，该TU-R可以执行步骤650-660。
下面结合步骤635-645对TU-R可以在超时前侦听到图5中的TU-O发送的上行注册窗口指示信号的具体实现方式进行描述。
步骤635，TU-R发送注册信息。
TU-R可以在超时前侦听到图5中的TU-O发送的上行注册窗口指示信号之后，可以在图5中的TU-O指定的上行注册窗口位置发送注册信息。
应理解，TU-R在指定的注册窗口位置发送的注册信息可以包括但不限于：TU-R唯一标识的ID(例如，介质访问控制层(media access control,MAC)地址)、循环冗余校验(cyclic redundancy check，CRC)等信息。
步骤640，判断TU-R是否注册成功。
TU-R在图4中的TU-O指定的上行注册窗口位置发送注册信息之后，可以判断是否可以正确接收到TU-O发送的响应消息。
如果该TU-R可以接收到TU-O发送的响应消息，该TU-R注册成功，可以执行步骤645。
如果该TU-R不能接收到TU-O发送的响应消息，该TU-R注册失败，可以重新执行步骤620。
步骤645，TU-R按照TU-O执行完成后续的交互进入数据阶段(show time)。
TU-R可以在注册成功之后，可以获取图5中的TU-O分配的ID，并可以按照TU-O指示的或预定义的模式进入后续的初始化流程，例如，handshake协议流程。并可以在初始化之后进入show time。
应理解，show time可以理解为TU-O和TU-R已经完成初始化过程，并可以开始在承载通道上发送数据。
下面结合步骤650-665对TU-R可以在超时前未侦听到图5中的TU-O发送的上行注册窗口指示信号的具体实现方式进行描述。
步骤650，计数器加1。
如果该TU-R可以在超时前在第一通道中没有侦听到图5中的TU-O发送的上行注册窗口指示信号，那么超时计数器可以加1。
步骤655，判断计数器是否超过阈值。
如果TU-R在计数器在超过阈值之前没有接收到TU-O发送的上行注册窗口指示信号，该TU-R可以重新执行步骤620。
如果TU-R在计数器在超过阈值之后还没有接收到TU-O发送的上行注册窗口指示信号，那么可能TU-O不支持P2MP工作模式，该TU-R可以执行步骤660。
步骤660，TU-R进行基于P2P的handshake交互。
TU-R可以在计数器在超过阈值之后还没有接收到TU-O发送的上行注册窗口指示信号之后，可以向TU-O发送handshake信号(例如，R-TONES-REQ信号)，并可以在进入P2P工作模式。并可以继续完成后续的handshake交互协议。
本申请实施例提供的终端设备，可以在P2MP的工作模式下，避免网络设备周期性的指示注册窗口，从而可以节约网络设备侧的资源开销以及节省耗电量。同时，该终端设备还可以同时兼容P2P工作模式的设备以及P2MP工作模式的设备。
下面结合图7中具体的例子，对应于图5，更加详细地描述本申请实施例中终端设备可以先侦听是否有网络设备发送的注册窗口指示信息，如果没有侦听到该窗口指示信息，该终端设备再在与handshake toneset不同的通道中发送第一指示信息的具体实现方式。应注意，图7的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据文所给出的图7的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图7是图3中的步骤310的另一种可能的终端设备的工作流程示意图。图7的方法可以包括步骤710-770，下面分别对步骤710-770进行详细描述。
应理解，图7的终端设备可以对应于图2所示的TU-R 236，下面以TU-R的工作流程 为例进行详细说明。
为了便于描述，本申请实施例中与handshake toneset不同的通道称为第一通道。
步骤710，判断TU-R是否支持P2MP工作模式。
TU-R可以在上电之后，可以判断该TU-R是否支持P2MP工作模式。如果该TU-R不支持P2MP工作模式(支持P2P工作模式)，可以执行步骤715。
如果该TU-R支持P2MP工作模式，可以执行步骤720。
步骤715，TU-R进入P2P工作模式。
TU-R可以在判断不支持P2MP工作模式(支持P2P工作模式)的情况下，可以进行基于P2P工作模式的handshake协议交互。
步骤720，TU-R侦听第一通道。
TU-R可以在判断支持P2MP工作模式的情况下，可以先侦听第一通道。
步骤725，判断TU-R在超时前是否能侦听到上行注册窗口指示信号。
判断TU-R在超时前是否可以在第一通道中侦听到网络设备(例如，图5中的TU-O)发送的上行注册窗口指示信号。
如果该TU-R可以在超时前在第一通道中侦听到TU-O发送的上行注册窗口指示信号，该TU-R可以执行步骤735-740。
如果该TU-R可以在超时前在第一通道中没有侦听到图5中的TU-O发送的上行注册窗口指示信号，该TU-R可以执行步骤745-750。
步骤730，TU-R发送注册信息。
TU-R可以在超时前侦听到图5中的TU-O发送的上行注册窗口指示信号之后，可以在图5中的TU-O指定的上行注册窗口位置发送注册信息。
应理解，TU-R在指定的注册窗口位置发送的注册信息可以包括但不限于：TU-R唯一标识的ID(例如，MAC地址)、循环冗余校验CRC等信息。
步骤735，判断TU-R是否注册成功。
TU-R在图4中的TU-O指定的上行注册窗口位置发送注册信息之后，可以判断是否可以正确接收到TU-O发送的响应消息。
如果该TU-R可以接收到TU-O发送的响应消息，该TU-R注册成功，可以执行步骤745。
如果该TU-R不能接收到TU-O发送的响应消息，该TU-R注册失败，可以重新执行步骤720。
步骤740，TU-R按照TU-O执行完成后续的交互进入show time。
TU-R可以在注册成功之后，可以获取图5中的TU-O分配的ID，并可以按照TU-O指示的或预定义的模式进入后续的初始化流程，例如，handshake协议流程。并可以在初始化之后进入show time。
应理解，show time可以理解为TU-O和TU-R已经完成初始化过程，并可以开始在承载通道上发送数据。
步骤745，TU-R在第一通道中发送特定信号。
如果TU-R支持P2MP工作模式，该TU-R可以在超时前未侦听到TU-O发送的上行注册窗口指示信号，该TU-R可以在第一通道中发送特定信号。例如，该特定信号可以是 上行注册窗口请求信息。
具体的，该特定信号可以是一个在一定时域和频域上承载的PN序列或ZC序列，还可以是一个在固定频段固定时间的有一定能量的信号。
步骤750，TU-R侦听第一通道。
TU-R可以在第一通道中发送特定信号之后，可以侦听第一通道。
步骤755，判断TU-R在超时前是否能侦听到上行注册窗口指示信号。
判断TU-R在超时前是否可以在第一通道中侦听到网络设备(例如，图5中的TU-O)发送的上行注册窗口指示信号。
如果该TU-R可以在超时前在第一通道中侦听到TU-O发送的上行注册窗口指示信号，该TU-R可以执行步骤730-735。
如果该TU-R可以在超时前在第一通道中没有侦听到图5中的TU-O发送的上行注册窗口指示信号，该TU-R可以执行步骤760-765。
TU-R可以在超时前侦听到图5中的TU-O发送的上行注册窗口指示信号的具体实现方式请参照上述步骤730-735的描述，此处不再赘述。
下面结合步骤760-770对TU-R可以在超时前未侦听到图5中的TU-O发送的上行注册窗口指示信号的具体实现方式进行描述。
步骤760，计数器加1。
如果该TU-R可以在超时前在第一通道中没有侦听到图5中的TU-O发送的上行注册窗口指示信号，那么超时计数器可以加1。
步骤765，判断计数器是否超过阈值。
如果TU-R在计数器在超过阈值之前没有接收到TU-O发送的上行注册窗口指示信号，该TU-R可以重新执行步骤720。
如果TU-R在计数器在超过阈值之后还没有接收到TU-O发送的上行注册窗口指示信号，那么可能TU-O不支持P2MP工作模式，该TU-R可以执行步骤770。
步骤770，TU-R进行基于P2P的handshake交互。
TU-R可以在计数器在超过阈值之后还没有接收到TU-O发送的上行注册窗口指示信号之后，可以向TU-O发送handshake信号(例如，R-TONES-REQ信号)，并可以在进入P2P工作模式。并可以继续完成后续的handshake交互协议。
图7提供的终端设备可以在图6的基础上，可以先侦听是否有网络设备发送的注册窗口指示信息，如果侦听到该窗口指示信息，新用户可以直接上线注册，从而可以简化新用户随机接入的注册流程。
本申请实施例提供的终端设备，可以在P2MP的工作模式下，避免网络设备周期性的指示注册窗口，从而可以节约网络设备侧的资源开销以及节省耗电量。同时，该终端设备还可以同时兼容P2P工作模式的设备以及P2MP工作模式的设备。
可选地，在一些实施例中，当指示信号可以是与现有的handshake toneset中的R-TONES-REQ信号的频带和形态相同的信号(例如，R-TONES-REQ信号)或与R-TONES-REQ信号的频带相同，但形态不相同的信号(例如，注册窗口请求信号)时，网络设备还可以在第一端口的handshake toneset中接收终端设备发送的R-TONES-REQ信号或注册窗口请求信号。下面会结合图8以及图11对上述两种实现方式进行描述。
下面结合图8中具体的例子，更加详细地描述本申请实施例中网络设备可以在第一端口的handshake toneset中接收终端设备发送的R-TONES-REQ信号的具体实现方式。应注意，图8的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据文所给出的图8的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图8是图3中的步骤310的另一种可能的网络设备的工作流程示意图。图8的方法可以包括步骤810-865，下面分别对步骤810-865进行详细描述。
应理解，图8中的网络设备可以对应于图2所示的TU-O 234，下面以TU-O的工作流程为例进行详细说明。
为了便于描述，本申请实施例中将与handshake toneset不同的通道称为第一通道。
步骤810，开始上电。
步骤812，TU-O侦测handshake toneset。
TU-O可以在上电之后，可以侦听一个端口的为handshake toneset(也可以称P2P通道)。
步骤815，判断TU-O是否可以在handshake toneset侦听到特定信号。
如果TU-O可以在handshake toneset中侦听到特定形态的信号，该TU-O可以执行步骤820。
如果TU-O没有在handshake toneset中侦听到特定信号，该TU-O可以重新执行步骤810。
应理解，handshake toneset中侦听到的特定信号的形态例如可以是R-TONES-REQ信号。
本申请实施例中handshake toneset中的R-TONES-REQ信号可以用于表示TU-R触发TU-O发送上行注册窗口请求的信号(触发TU-O进入P2MP工作模式)，还可以用于表示TU-R触发TU-O进入P2P工作模式的信号。本申请对此不做具体限定。
步骤820，TU-O发送上行注册窗口指示信号，同时在handshake通道按照协议基于P2P进行交互。
本申请实施例中，TU-O可以在handshake toneset中侦听到特定信号之后，可以第一通道发送上行注册窗口指示信号，可以在handshake toneset发送上行注册窗口指示信号，本申请实施例对此不做具体限定。
TU-O可以在发送上行注册窗口指示信号之后，可以同时在handshake toneset按照协议基于P2P进行交互。
应理解，TU-O可以同时兼容P2MP设备和P2P设备，TU-R可以选择P2MP的工作模式也可以选择P2P的工作模式。
可选地，在一些实施例中，TU-O还可以在发送上行注册窗口指示信号之前，可以先发送一段训练序列，该训练序列可以用于终端设备(例如，TU-R)的下行信道的同步和训练。
步骤825，判断TU-O是否能接收到C-SLIENT1，再侦测到R-TONE1信号。
如果TU-O可以先在handshake toneset接收到TU-R发送的C-SLIENT1信号，再接收到TU-R发送的R-TONE1信号(说明TU-R可能仅支持P2P工作模式)，TU-O可以执行 步骤830。该TU-O可以进入P2P的工作模式，可以选择按照handshake通道流程进行后续的handshake交互。
如果TU-O没有在handshake toneset中接收到TU-R发送的C-SLIENT1以及R-TONE1信号，TU-O可以执行步骤835。该TU-O可以在指示的上行注册窗口的位置检测是否有TU-R发送的上行注册信息。
步骤830，TU-O关闭第一通道，进入P2P工作模式。
TU-O可以在handshake toneset中接收到TU-R发送的R-TONE1信号之后，可以关闭第一通道，进入P2P工作模式，并可以继续完成后续的handshake交互协议。
需要说明的是，如果之后TU-O工作在P2P工作模式，该TU-O不再支持P2MP的工作模式。
步骤835，判断新用户是否注册成功。
如果TU-O没有在handshake toneset中接收到TU-R发送的R-TONE1信号，该TU-O可以在指示的上行注册窗口的位置检测是否有TU-R发送的上行注册信息。
如果TU-O可以在指示的注册窗口内检测到TU-R发送的上行注册信息，并可以响应正确解析的上行注册信息，TU-O可以完成新用户的注册。该TU-O可以进入步骤840，并工作在P2MP的工作模式下。
如果TU-O没有在指示的注册窗口内检测到TU-R发送的上行注册信息，那么该TU-O可以重新进入步骤810，可以重新对handshake toneset进行侦听。
步骤840，关闭handshake流程，进入P2MP工作模式。
如果TU-O可以在指示的注册窗口内检测到TU-R发送的上行注册信息，并可以响应正确解析的上行注册信息，TU-O可以完成新用户的注册。TU-O可以关闭handshake流程，进入P2MP工作模式。
TU-O可以在进入P2MP工作模式之后，可以对于已经注册成功的TU-R分配一个ID。该TU-O可以指定TU-R进入后续的初始化流程，例如，handshake协议流程。
需要说明的是，如果TU-O已经工作在P2MP工作模式，那么后续该TU-O可以执行步骤845-865，可以在handshake toneset中侦听到特定信号之后，仅在第一通道发送上行注册窗口指示信号。
步骤845，TU-O侦测handshake toneset。
TU-O可以侦听一个端口的handshake toneset。
步骤850，判断TU-O是否可以在handshake toneset侦听到特定信号。
如果TU-O可以在handshake toneset中侦听到特定形态的信号(该特定形态的信号例如可以是R-TONES-REQ信号)，该TU-O可以执行步骤855。
如果TU-O没有在handshake toneset中侦听到特定信号，该TU-O可以重新执行步骤845。
步骤855，TU-O在第一通道发送上行注册窗口指示信号。
TU-O可以在进入P2MP工作模式之后，如果该TU-O在handshake toneset中侦听到特定信号之后，仅在第一发送上行注册窗口指示信号。不再响应非指定的handshake的信号。
步骤860，判断新用户是否注册成功。
如果TU-O可以在指示的注册窗口内检测到TU-R发送的上行注册信息，并可以响应正确解析的上行注册信息，该TU-O可以完成新用户的注册，并可以进入步骤865。
如果TU-O没有在指示的注册窗口内检测到TU-R发送的上行注册信息，那么该TU-O可以重新进入步骤845，重新对handshake toneset进行侦听。
步骤865，TU-O指定新注册用户完成handshake流程，并进行第一通道侦测。
TU-O可以在进入P2MP工作模式之后，可以对于已经注册成功的TU-R分配一个ID。该TU-O可以指定TU-R进入后续的初始化流程，例如，handshake协议流程。
本申请实施例提供的网络设备，可以P2MP的工作模式下，避免周期性的指示注册窗口，从而可以节约资源开销以及节省耗电量。同时，该网络设备还可以同时兼容P2P工作模式的设备以及P2MP工作模式的设备。
对应于图8所示的网络设备在第一端口的handshake toneset中接收终端设备(例如，TU-R)发送的R-TONES-REQ信号，本申请实施例中终端设备发送R-TONES-REQ信号的实现方式同样有两种实现方式。作为一个示例，终端设备在判断可以支持P2MP的工作模式之后，直接可以在handshake toneset中发送R-TONES-REQ信号。作为另一个示例，终端设备可以先侦听是否有网络设备发送的注册窗口指示信息，如果没有，终端设备再在handshake toneset中发送R-TONES-REQ信号。
下面结合图9中具体的例子，对应于图8，更加详细地描述本申请实施例中终端设备在判断可以支持P2MP的工作模式之后，可以在handshake toneset中发送第一指示信息的具体实现方式。应注意，图9的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据文所给出的图9的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图9是图3中的步骤310的另一种可能的终端设备的工作流程示意图。图9的方法可以包括步骤910-975，下面分别对步骤910-975进行详细描述。
应理解，图9的终端设备可以对应于图2所示的TU-R 236，下面以TU-R的工作流程为例进行详细说明。
为了便于描述，本申请实施例中将与handshake toneset不同的通道称为第一通道。
步骤910，判断TU-R是否支持P2MP工作模式。
TU-R可以在上电之后，可以判断该TU-R是否支持P2MP工作模式。如果该TU-R不支持P2MP工作模式(支持P2P工作模式)，可以执行步骤915。如果该TU-R支持P2MP工作模式，可以执行步骤920。
步骤915，TU-R进入P2P工作模式。
TU-R可以在判断不支持P2MP工作模式(支持P2P工作模式)的情况下，可以进行基于P2P工作模式的handshake协议交互。
步骤920，TU-R侦听下行handshake toneset。
TU-R可以在判断支持P2MP工作模式的情况下，可以先侦听handshake toneset，看侦听handshake toneset中是否有其他正在交互的handshake协议信号。
应理解，如果TU-R在支持P2MP工作模式，想要在handshake通道上发送特定形态的信号，该TU-R可以先侦听handshake toneset中是否有其他正在交互的handshake协议 信号。如果handshake toneset中有正在交互的handshake协议信号，可以等handshake流程完成之后，在handshake toneset上发送特定形态的信号，可以避免信号干扰。
步骤925，判断TU-R在超时前是否能侦听到handshake信号。
如果TU-R在超时前，可以侦听到handshake toneset中正在交互的handshake协议信号，可以执行步骤930。
如果TU-R在超时前，未能侦听到handshake toneset中正在交互的handshake协议信号，可以执行步骤935。
步骤930，等待handshake流程完成。
TU-R在可以在判断handshake toneset中有正在交互的handshake协议信号，可以等handshake流程完成之后，在handshake toneset上发送特定形态的信号，可以避免信号干扰。
TU-R可以在等handshake流程完成之后，可以继续执行步骤940，TU-R侦听handshake toneset，判断在超时前handshake toneset中是否有其他正在交互的handshake协议信号。
步骤935，TU-R在handshake toneset发送特定信号。
TU-R可以在超时前，未能侦听到handshake toneset中正在交互的handshake协议信号的情况下，可以在handshake toneset中发送上行注册信息请求信号。
应理解，TU-R在handshake toneset中发送的上行注册信息请求信号可以是handshake通道中的R-TONES-REQ信号。也可以是其他信号，例如，在一定时间或频带内承载的能量信号或者差分编码二相移键控(differentially encoded binary phase shift keying，DPSK)调制的序列。
本申请实施例中handshake toneset中的R-TONES-REQ信号可以用于表示触发TU-O发送上行注册窗口请求的信号(触发TU-O进入P2MP工作模式)，还可以用于表示触发TU-O进入P2P工作模式的信号。本申请对此不做具体限定。
步骤940，TU-R侦听第一通道和handshake toneset。
TU-R可以在handshake通道中发送特定形态的信号之后，可以侦听第一通道和handshake toneset。
步骤945，判断TU-R在超时之前是否能侦听到上行注册窗口指示信号。
如果TU-R在超时之前可以侦听到网络设备(例如，图8中的TU-O)发送的上行注册窗口指示信号，可以理解为TU-O也可以支持P2MP工作模式，该TU-R可以执行步骤950-955。
本申请实施例中，TU-R可以在handshake toneset中侦听到上行注册窗口指示信号，还可以在第一通道中侦听到上行注册窗口指示信号，本申请实施例对此不做具体限定。
如果TU-R在超时之前没有侦听到上行注册窗口指示信号，可以理解为TU-O不支持P2MP工作模式(支持P2P工作模式)，该TU-R可以执行步骤965-975。
步骤950，TU-R发送注册消息，终止handshake协议交互。
如果TU-R可以在超时前侦听到图8中的TU-O发送的上行注册窗口指示信号之后，可以在图8中的TU-O指定的上行注册窗口位置发送注册信息。同时，该TU-R可以终止handshake交互。
应理解，TU-R在指定的注册窗口位置发送的注册信息可以包括但不限于：TU-R唯一 标识的ID(例如，MAC地址)、CRC等信息。
步骤955，判断TU-R是否注册成功。
TU-R在图8中的TU-O指定的上行注册窗口位置发送注册信息之后，可以判断是否可以正确接收到TU-O发送的响应消息。
如果该TU-R可以接收到TU-O发送的响应消息，该TU-R注册成功，可以执行步骤960。
如果该TU-R不能接收到TU-O发送的响应消息，该TU-R注册失败，可以重新执行步骤920。
步骤960，TU-R按照TU-O执行完成后续的交互进入show time。
TU-R可以在注册成功之后，可以获取图8中的TU-O分配的ID，并可以按照TU-O指示的或预定义的模式进入后续的初始化流程，例如，handshake协议流程。并可以在初始化之后进入show time。
应理解，show time可以理解为TU-O和TU-R已经完成初始化过程，并可以开始在承载通道上发送数据。
下面结合步骤965-975对TU-R可以在超时前未侦听到图8中的TU-O发送的上行注册窗口指示信号的具体实现方式进行描述。
步骤965，计数器加1。
如果该TU-R可以在超时前没有侦听到图8中的TU-O发送的上行注册窗口指示信号，那么超时计数器可以加1。
步骤970，判断计数器超过阈值。
如果TU-R在计数器在超过阈值之前没有接收到TU-O发送的上行注册窗口指示信号，该TU-R可以重新执行步骤920。
如果TU-R在计数器在超过阈值之后还没有接收到TU-O发送的上行注册窗口指示信号，并且收到handshake后续信号的响应信号(例如，C-TONES信号)，那么可能TU-O不支持P2MP工作模式，该TU-R可以执行步骤975。
步骤975，TU-R进行基于P2P的handshake交互。
TU-R可以在计数器在超过阈值之后还没有接收到TU-O发送的上行注册窗口指示信号之后，可以向TU-O发送handshake信号(例如，R-TONES-REQ信号)，并可以在进入P2P工作模式。并可以继续完成后续的handshake交互协议。
下面结合图10中具体的例子，对应于图8，更加详细地描述本申请实施例中终端设备可以先侦听是否有网络设备发送的注册窗口指示信息，如果没有侦听到该窗口指示信息，该终端设备再在handshake toneset中发送R-TONES-REQ信号的具体实现方式。应注意，图10的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据文所给出的图10的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图10是图3中的步骤310的另一种可能的终端设备的工作流程示意图。图10的方法可以包括步骤1010-1095，下面分别对步骤1010-1095进行详细描述。
应理解，图10的终端设备可以对应于图2所示的TU-R 254，下面以TU-R的工作流程为例进行详细说明。
为了便于描述，本申请实施例中将与handshake toneset不同的通道称为第一通道。
步骤1010，判断TU-R是否支持P2MP工作模式。
TU-R可以在上电之后，可以判断该TU-R是否支持P2MP工作模式。如果该TU-R不支持P2MP工作模式(支持P2P工作模式)，可以执行步骤1015。如果该TU-R支持P2MP工作模式，可以执行步骤1020。
步骤1015，TU-R进入P2P工作模式。
TU-R可以在判断不支持P2MP工作模式(支持P2P工作模式)的情况下，可以进行基于P2P工作模式的handshake协议交互。
步骤1020，判断TU-R在超时之前是否能侦听到上行注册窗口指示信号。
如果TU-R在超时之前可以侦听到网络设备(例如，图8中的TU-O)发送的上行注册窗口指示信号，可以理解为TU-O也可以支持P2MP工作模式，该TU-R可以执行步骤1025-1030。
如果TU-R在超时之前没有侦听到上行注册窗口指示信号，可以理解为TU-O不支持P2MP工作模式(支持P2P工作模式)，该TU-R可以执行步骤1040-1045。
步骤1025，TU-R发送注册消息，终止handshake交互。
如果TU-R可以在超时前侦听到图8中的TU-O发送的上行注册窗口指示信号之后，可以在图8中的TU-O指定的上行注册窗口位置发送注册信息。同时，该TU-R可以终止handshake交互。
应理解，TU-R在指定的注册窗口位置发送的注册信息可以包括但不限于：TU-R唯一标识的ID(例如，MAC地址)、CRC等信息。
步骤1030，判断TU-R是否注册成功。
TU-R在图8中的TU-O指定的上行注册窗口位置发送注册信息之后，可以判断是否可以正确接收到TU-O发送的响应消息。
如果该TU-R可以接收到TU-O发送的响应消息，该TU-R注册成功，可以执行步骤1035。
如果该TU-R不能接收到TU-O发送的响应消息，该TU-R注册失败，可以重新执行步骤1020。
步骤1035，TU-R按照TU-O执行完成后续的交互进入show time。
TU-R可以在注册成功之后，可以获取图8中的TU-O分配的ID，并可以按照TU-O指示的或预定义的模式进入后续的初始化流程，例如，handshake协议流程。并可以在初始化之后进入show time。
应理解，show time可以理解为TU-O和TU-R已经完成初始化过程，并可以开始在承载通道上发送数据。
步骤1040，TU-R侦听下行handshake toneset。
TU-R可以在判断支持P2MP工作模式的情况下，可以先侦听handshake通道，看侦听handshake通道中是否有其他正在交互的handshake协议信号。
应理解，如果TU-R在支持P2MP工作模式，想要在handshake通道上发送特定形态的信号，该TU-R可以先侦听handshake通道中是否有其他正在交互的handshake协议信号。如果handshake通道中有正在交互的handshake协议信号，可以等handshake流程完成 之后，在handshake通道上发送特定形态的信号，可以避免信号干扰。
步骤1045，判断TU-R在超时前是否能侦听到handshake协议信号。
如果TU-R在超时前，可以侦听到handshake通道中正在交互的handshake协议信号，可以执行步骤1050。
如果TU-R在超时前，未能侦听到handshake通道中正在交互的handshake协议信号，可以执行步骤1055。
步骤1050，等待handshake流程完成。
TU-R在可以在判断handshake通道中有正在交互的handshake协议信号，可以等handshake流程完成之后，在handshake通道上发送特定形态的信号，可以避免信号干扰。
TU-R可以在等handshake流程完成之后，可以继续执行步骤1040，TU-R侦听下行handshake通道，判断在超时前handshake通道中是否有其他正在交互的handshake协议信号。
步骤1055，TU-R在handshake toneset通道发送特定信号。
TU-R可以在超时前，未能侦听到handshake通道中正在交互的handshake协议信号的情况下，可以在handshake通道中发送上行注册信息请求信号。
应理解，TU-R在handshake通道中发送的上行注册信息请求信号可以是handshake通道中的R-TONES-REQ信号。也可以是其他信号，例如，在一定时间或频带内承载的能量信号或者差分编码二相移键控(differentially encoded binary phase shift keying，DPSK)调制的序列。
步骤1060，TU-R侦听第一通道和handshake toneset。
TU-R可以在handshake通道中发送特定形态的信号之后，可以侦听第一通道和handshake toneset。
步骤1065，判断TU-R在超时之前是否能侦听到上行注册窗口指示信号。
如果TU-R在超时之前可以在第一通道中侦听到网络设备(例如，图8中的TU-O)发送的上行注册窗口指示信号，可以理解为TU-O也可以支持P2MP工作模式，该TU-R可以执行步骤1070-1075。
如果TU-R在超时之前没有在第一通道中侦听到上行注册窗口指示信号，可以理解为TU-O不支持P2MP工作模式(支持P2P工作模式)，该TU-R可以执行步骤1085-10105。
步骤1070，TU-R发送注册消息，终止handshake交互。
如果TU-R可以在超时前侦听到图8中的TU-O发送的上行注册窗口指示信号之后，可以在图8中的TU-O指定的上行注册窗口位置发送注册信息。同时，该TU-R可以终止handshake交互。
应理解，TU-R在指定的注册窗口位置发送的注册信息可以包括但不限于：TU-R唯一标识的ID(例如，MAC地址)、CRC等信息。
步骤1075，判断TU-R是否注册成功。
TU-R在图8中的TU-O指定的上行注册窗口位置发送注册信息之后，可以判断是否可以正确接收到TU-O发送的响应消息。
如果该TU-R可以接收到TU-O发送的响应消息，该TU-R注册成功，可以执行步骤1080。
如果该TU-R不能接收到TU-O发送的响应消息，该TU-R注册失败，可以重新执行步骤1040。
步骤1080，TU-R按照TU-O执行完成后续的交互进入show time。
TU-R可以在注册成功之后，可以获取图8中的TU-O分配的ID，并可以按照TU-O指示的或预定义的模式进入后续的初始化流程，例如，handshake协议流程。并可以在初始化之后进入show time。
步骤1085，计数器加1。
如果该TU-R可以在超时前没有侦听到图8中的TU-O发送的上行注册窗口指示信号，那么超时计数器可以加1。
步骤1090，判断计数器是否超过阈值。
如果TU-R在计数器在超过阈值之前没有接收到TU-O发送的上行注册窗口指示信号，该TU-R可以重新执行步骤1040。
如果TU-R在计数器在超过阈值之后还没有接收到TU-O发送的上行注册窗口指示信号，并且收到handshake后续信号的响应信号(例如，C-TONES信号)，那么可能TU-O不支持P2MP工作模式，该TU-R可以执行步骤1095。
步骤1095，TU-R进行基于P2P的handshake交互。
TU-R可以在计数器在超过阈值之后还没有接收到TU-O发送的上行注册窗口指示信号之后，可以向TU-O发送handshake信号(例如，R-TONES-REQ信号)，并可以在进入P2P工作模式。继续完成后续的handshake交互协议。
图10提供的终端设备可以在图9的基础上，可以先侦听是否有网络设备发送的注册窗口指示信息，如果侦听到该窗口指示信息，新用户可以直接上线注册，从而可以简化新用户随机接入的注册流程。
可选地，在一些实施例中，当指示信号还可以是与现有的handshake toneset中的R-TONES-REQ信号的频带相同，但形态不相同的信号(例如，上行注册窗口请求信号)网络设备还可以在第一端口的handshake toneset中接收终端设备发送的上行注册窗口请求信号。其中，上行注册窗口请求信号可以用于表示终端设备进行P2MP的工作模式。
下面结合图11中具体的例子，更加详细地描述本申请实施例中网络设备可以在第一端口的handshake toneset中接收终端设备发送的与现有的handshake toneset中的R-TONES-REQ信号的频带相同，但形态不相同的注册窗口请求信号的具体实现方式。应注意，图11的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据文所给出的图11的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图11是图3中的步骤310的另一种可能的网络设备的工作流程示意图。图11的方法可以包括步骤1110-1190，下面分别对步骤1110-1190进行详细描述。
应理解，图11中的网络设备可以对应于图2所示的TU-O 234，下面以TU-O的工作流程为例进行详细说明。
为了便于描述，本申请实施例中将与handshake toneset不同的通道称为第一通道。
步骤1110，TU-O侦测R-TONE-REQ信号或注册窗口请求信号。
TU-O可以在上电之后，可以在handshake toneset中侦听TU-R发送的R-TONE-REQ 信号或注册窗口请求信号。
如果TU-O可以在handshake toneset侦听到TU-R发送的R-TONE-REQ信号，可以用于表示该TU-R进行P2P的工作模式。
如果TU-O可以在handshake toneset侦听到TU-R发送的注册窗口请求信号，可以用于表示该TU-R进行P2MP的工作模式。
步骤1120，TU-O是否支持P2MP工作模式以及是否可以侦测到注册窗口请求信号。
如果TU-O不支持P2MP的工作模式，并且没有在handshake toneset中侦测到TU-R发送的注册窗口请求信号，该TU-O可以执行步骤1130-1140。
如果TU-O支持P2MP的工作模式，并且在handshake toneset中侦测到TU-R发送的注册窗口请求信号，该TU-O可以执行步骤1150-1170。
步骤1130，TU-O是否支持P2P工作模式以及是否可以侦测到R-TONE-REQ信号。
如果TU-O支持P2P工作模式，并且可以在handshake toneset中侦测到TU-R发送的R-TONE-REQ信号，该TU-O可以执行步骤1140。
如果TU-O不支持P2P工作模式，并且没有在handshake toneset中侦测到TU-R发送的R-TONE-REQ信号，该TU-O可以重新执行步骤1110。
步骤1140，TU-O进入P2P工作模式，并继续完成handshake交互。
TU-O可以在handshake toneset中接收到TU-R发送的R-TONE-REQ信号之后，可以进入P2P工作模式，并可以继续完成后续的handshake交互协议。
需要说明的是，如果之后TU-O工作在P2P工作模式，该TU-O不再支持P2MP的工作模式。
步骤1150，TU-O发送注册窗口指示信号。
TU-O可以在支持P2MP的工作模式，并且在handshake toneset中侦测到TU-R发送的注册窗口请求信号之后，该TU-O可以发送注册窗口指示信号。
步骤1160，判断TU-O是否可以侦测到TU-R的ID。
TU-O可以在发送C-IND信号之后，可以判断是否可以侦测TU-R发送的注册信息，该注册信息中可以包含TU-R的唯一标识ID。该TU-R的ID例如可以是介质访问控制(media access control，MAC)层地址。
如果TU-O可以在指示的注册窗口内侦测到TU-R发送的注册信息，该注册信息包括TU-R的ID，该TU-O可以执行步骤1180。
如果TU-O没有侦测到TU-R的ID，该TU-O可以重新执行步骤1110。
步骤1180，TU-O发送携带ID的响应消息。
如果TU-O可以在指示的注册窗口内检测到TU-R发送的上行注册信息，并可以响应正确解析的上行注册信息。
步骤1190，TU-O指定新注册用户完成handshake流程，并进行handshake toneset侦测。
TU-O可以在进入P2MP工作模式之后，可以对于已经注册成功的TU-R分配一个ID。该TU-O可以指定TU-R进入后续的初始化流程，例如，handshake协议流程。
对应于图11所示的网络设备在第一端口的handshake toneset中接收终端设备(例如，TU-R)发送的注册窗口请求信号，本申请实施例中终端设备发送注册窗口请求信号的实 现方式同样有两种实现方式。作为一个示例，终端设备可以在handshake toneset中发送R-TONE-REQ信号或注册窗口请求信号。作为另一个示例，终端设备可以先侦听是否有网络设备发送的注册窗口指示信息，如果没有，终端设备再在handshake toneset中发送R-TONE-REQ信号或注册窗口请求信号。
下面结合图12中具体的例子，对应于图11，更加详细地描述本申请实施例中终端设备可以先侦听是否有网络设备发送的注册窗口指示信息，如果没有，终端设备再在handshake toneset中发送R-TONE-REQ信号或注册窗口请求信号的具体实现方式。应注意，图12的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据文所给出的图12的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图12是图3中的步骤310的另一种可能的终端设备的工作流程示意图。图12的方法可以包括步骤1210-1265，下面分别对步骤1210-1265进行详细描述。
应理解，图12的终端设备可以对应于图2所示的TU-R 236，下面以TU-R的工作流程为例进行详细说明。
为了便于描述，本申请实施例中将与handshake toneset不同的通道称为第一通道。
步骤1210，TU-R检测TU-O发送的注册窗口指示信息。
步骤1215，判断TU-R在超时之前是否检测到注册窗口指示信息。
如果TU-R可以在超时之前检测到TU-O发送的注册窗口指示信息，该TU-R可以执行步骤1220-1225。
如果TU-R未在超时之前检测到TU-O发送的注册窗口指示信息，该TU-R可以执行步骤1235-1245。
步骤1220，TU-R向TU-O发送TU-R的注册ID。
TU-R可以在超时之前检测到TU-O发送的注册窗口指示信息，该TU-R可以向TU-O发送注册信息，该注册信息中可以包括该TU-R的ID。该TU-R的ID可以用于表示TU-R的MAC地址。
步骤1225，判断TU-R是否注册成功。
TU-R在图11中的TU-O指定的上行注册窗口位置发送注册信息之后，可以判断是否可以正确接收到TU-O发送的响应消息。
如果该TU-R可以接收到TU-O发送的响应消息，该TU-R注册成功，可以执行步骤1230。
如果该TU-R不能接收到TU-O发送的响应消息，该TU-R注册失败，可以重新执行步骤1210。
步骤1230，TU-R按照TU-O执行完成后续的交互进入show time。
TU-R可以在注册成功之后，可以获取图11中的TU-O分配的ID，并可以按照TU-O指示的或预定义的模式进入后续的初始化流程，例如，handshake协议流程。并可以在初始化之后进入show time。
步骤1235，计数器加1，判断计数器是否超过阈值。
如果该TU-R可以在超时前没有侦听到图11中的TU-O发送的上行注册窗口指示信号，那么超时计数器可以加1。
如果TU-R的计数器超过阈值，那么可能TU-O不支持P2MP工作模式，该TU-R可以执行步骤1240。
如果TU-R的计数器没有超过阈值，该TU-R可以执行步骤1255。
步骤1240，TU-R发送R-TONE-REQ信号，并进入P2P工作模式。
如果TU-R的计数器超过阈值，那么可能TU-O不支持P2MP工作模式，该TU-R可以向TU-O发送R-TONE-REQ信号，该信号可以用于表示TU-R进入P2P工作模式。
步骤1245，判断TU-R握手是否失败。
TU-R可以在向TU-O发送R-TONE-REQ信号之后，并可以在进入P2P工作模式，可以继续完成后续的handshake交互协议。
如果TU-R握手(handshake)成功，该TU-R可以执行步骤1250。
如果TU-R握手(handshake)失败，该TU-R可以重新执行步骤1210。
步骤1250，TU-R进行握手之后的初始化。
TU-R可以在握手(handshake)成功之后，可以进入初始化阶段。
步骤1255，TU-R检测现有的握手handshake。
如果TU-R的计数器没有超过阈值，该TU-R可以检测现有的handshake。
步骤1260，判断TU-R是否在超时之前退出handshake检测。
如果TU-R在超时之前，可以退出handshake检测，该TU-R可以执行步骤1265。
如果TU-R在超时之前，没有退出handshake检测，该TU-R可以重新执行步骤1255。
步骤1265，TU-R发送上行注册窗口请求信号(例如，注册窗口请求信号)。
TU-R可以在向TU-O发送注册窗口请求信号之后，可以继续执行步骤1210，可以继续侦测TU-O发送的注册窗口指示信息。
可选地，在一些实施例中，TU-R还可以不用执行步骤1210中的先侦测TU-O是否发送了注册窗口指示信息，可以直接发送注册窗口指示信息。
上文结合图1至图12，详细描述了本发明实施例提供的一种上行接入的方法，下面将结合图13至图16，详细描述本申请的装置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
图13示出了本申请实施例的网络设备1300的示意性框图，该网络设备1300中各模块分别用于执行上述方法中网络设备所执行的各动作或处理过程，这里，为了避免赘述，详细说明可以参照上文中的描述。
图13是本申请实施例提供的网络设备1300的示意性框图。该网络设备1300可以包括：
第一接收模块1310，用于接收终端设备在上线时发送的第一指示信息；
发送模块1320，用于根据所述第一指示信息，在所述第一端口中发送上行注册窗口指示信息。
可选地，在一些实施例中，所述第一接收模块1310具体用于：在所述第一端口的第一通道中接收所述终端设备发送的第一指示信息，所述第一指示信息为与第二通道的频带不同的信号。
可选地，在一些实施例中，所述第一接收模块1310还具体用于：在所述第一端口的所述第二通道中接收所述终端设备发送的第二指示信息，所述第二指示信息为与所述第二 通道的频带相同的信号。
可选地，在一些实施例中，当所述第二指示信息为与第二通道现有的握手协议中R-TONES-REQ信号频带相同，但信号形态不同的信号时，发送模块1320具体用于：根据所述第一指示信息，在所述第一端口的第一通道中发送所述上行注册窗口指示信息。
可选地，在一些实施例中，当所述第二信息为与第二通道现有的握手协议中R-TONES-REQ信号形态相同的信号时，所述发送模块1320还用于：在所述第一端口的第二通道进行所述握手协议流程。
图14示出了本申请实施例的终端设备1400的示意性框图，该终端设备1400中各模块分别用于执行上述方法中网络设备所执行的各动作或处理过程，这里，为了避免赘述，详细说明可以参照上文中的描述。
图14是本申请实施例提供的终端设备1400的示意性框图。该终端设备1400可以包括：
第一发送模块1410，用于上线时在第一端口向网络设备发送指示信息；
第一接收模块1420，用于在所述第二端口中接收所述网络设备发送的上行注册窗口指示信息。
其中，所述第一指示信息用于触发所述网络设备在第一端口发送上行注册窗口指示信息，所述上行注册窗口指示信息用于指示所述终端设备在指示的注册窗口位置发送上行注册信息。
应理解，所述第二端口与所述网络设备接收所述指示信息的第一端口对应。
可选地，在一些实施例中，所述第一发送模块1410具体用于：所述终端设备在所述第二端口的第一通道中向所述网络设备发送第一指示信息，所述第一指示信息为与第二通道的频带不同的信号。
可选地，在一些实施例中，所述第一发送模块1410具体用于：所述终端设备在所述第二端口的第二通道中向所述网络设备发送第二指示信息，所述第二指示信息为与所述第二通道的频带相同的信号。
可选地，在一些实施例中，所述终端设备1400还包括：处理模块1430，
该处理模块1430用于：当终端设备在所述第二通道上侦听到现有的握手协议信号，所述终端设备等待所述握手协议流程完成。
可选地，在一些实施例中，所述终端设备还包括：第二发送模块1440，
该第二发送模块1440具体用于：在超时之前在所述第二端口未接收到所述上行注册窗口指示信息的情况下，所述终端设备在所述第二端口的第二通道中向所述网络设备发送所述第二指示信息。
可选地，在一些实施例中，所述终端设备1400还包括：第二接收模块1450，
该第二接收模块1450具体用于：在所述第二端口的第一通道中接收到所述上行注册窗口指示信息的情况下，所述终端设备在指示的注册窗口位置向所述网络设备发送注册信息。
图15是本申请实施例提供的一种网络设备1500的示意性框图。该网络设备1500可以包括：处理器1501、接收器1502、发送器1503、以及存储器1504。
其中，该处理器1501可以与接收器1502和发送器1503通信连接。该存储器1504可 以用于存储该网络设备的程序代码和数据。因此，该存储器1504可以是处理器1501内部的存储单元，也可以是与处理器1501独立的外部存储单元，还可以是包括处理器1501内部的存储单元和与处理器1501独立的外部存储单元的部件。
可选的，IoT平台1500还可以包括总线1505。其中，接收器1502、发送器1503、以及存储器1504可以通过总线1505与处理器1501连接；总线1505可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。所述总线1505可以分为地址总线、数据总线、控制总线等。为便于表示，图15中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
处理器1501例如可以是中央处理器(central processing unit，CPU)，通用处理器，数字信号处理器(digital signal processor，DSP)，专用集成电路(application-specific integrated circuit，ASIC)，现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。
接收器1502和发送器1503可以是包括上述天线和发射机链和接收机链的电路，二者可以是独立的电路，也可以是同一个电路。
当程序被执行时，所述接收器1502用于：接收终端设备在上线时发送的指示信息。
发送器1503通过所述处理器1501执行以下操作：用于根据所述一指示信息，在第一端口中发送上行注册窗口指示信息。
可选地，在一些实施例中，接收器1502具体用于：在所述第一端口的第一通道中接收所述终端设备发送的第一指示信息，所述第一指示信息为与第二通道的频带不同的信号。
可选地，在一些实施例中，接收器1502还具体用于：在所述第一端口的所述第二通道中接收所述终端设备发送的第二指示信息，所述第二指示信息为与所述第二通道的频带相同的信号。
可选地，在一些实施例中，当所述第二指示信息为与第二通道现有的握手协议中R-TONES-REQ信号频带相同，但信号形态不同的信号时，发送器1503具体用于：根据所述第一指示信息，在所述第一端口的第一通道中发送所述上行注册窗口指示信息。
可选地，在一些实施例中，当所述第二信息为与第二通道现有的握手协议中R-TONES-REQ信号形态相同的信号时，所述发送器1503还用于：在所述第一端口的第二通道进行所述握手协议流程。
图16是本申请实施例提供的一种终端设备1600的示意性框图。该终端设备1600可以包括：处理器1601、接收器1602、发送器1603、以及存储器1604。
其中，该处理器1601可以与接收器1602和发送器1603通信连接。该存储器1604可以用于存储该终端设备的程序代码和数据。因此，该存储器1604可以是处理器1601内部的存储单元，也可以是与处理器1601独立的外部存储单元，还可以是包括处理器1601内部的存储单元和与处理器1601独立的外部存储单元的部件。
可选的，IoT平台1600还可以包括总线1605。其中，接收器1602、发送器1603、以 及存储器1604可以通过总线1605与处理器1601连接；总线1605可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。所述总线1605可以分为地址总线、数据总线、控制总线等。为便于表示，图16中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
处理器1601例如可以是中央处理器(central processing unit，CPU)，通用处理器，数字信号处理器(digital signal processor，DSP)，专用集成电路(application-specific integrated circuit，ASIC)，现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。
接收器1602和发送器1603可以是包括上述天线和发射机链和接收机链的电路，二者可以是独立的电路，也可以是同一个电路。
当程序被执行时，发送器1603用于：上线时在第二端口向网络设备发送指示信息；
接收器1602用于：在所述第二端口中接收所述网络设备发送的上行注册窗口指示信息。
其中，所述第一指示信息用于触发所述网络设备在第一端口发送上行注册窗口指示信息，所述上行注册窗口指示信息用于指示所述终端设备在指示的注册窗口位置发送上行注册信息。
应理解，所述第二端口与所述网络设备接收所述指示信息的第一端口对应。
可选地，在一些实施例中，所述发送器1603具体用于：所述终端设备在所述第二端口的第一通道中向所述网络设备发送第一指示信息，所述第一指示信息为与第二通道的频带不同的信号。
可选地，在一些实施例中，所述发送器1603具体用于：所述终端设备在所述第二端口的第二通道中向所述网络设备发送第二指示信息，所述第二指示信息为与所述第二通道的频带相同的信号。
可选地，在一些实施例中，处理器1601用于：当终端设备在所述第二通道上侦听到现有的握手协议信号，所述终端设备等待所述握手协议流程完成。
可选地，在一些实施例中，所述发送器1603还具体用于：在超时之前在所述第二端口未接收到所述上行注册窗口指示信息的情况下，所述终端设备在所述第二端口的第二通道中向所述网络设备发送所述第二指示信息。
可选地，在一些实施例中，所述发送器1603还具体用于：在所述第二端口的第一通道中接收到所述上行注册窗口指示信息的情况下，所述终端设备在指示的注册窗口位置向所述网络设备发送注册信息。
本申请实施例还提供了一种芯片，包括存储器、处理器，收发器，所述存储器用于存储程序；所述处理器用于执行所述存储器中存储的程序，当所述程序被执行时，所述处理器执行上述网络设备中任意一种可能的实现方式中所述的方法。
本申请实施例还提供了一种芯片，包括存储器、处理器，收发器，所述存储器用于存储程序；所述处理器用于执行所述存储器中存储的程序，当所述程序被执行时，所述处理 器执行上述终端设备中任意一种可能的实现方式中所述的方法。
本申请实施例还提供了一种计算机可读存储介质，包括计算机程序，当该计算机程序在计算机上运行时，使得该计算机执行如步骤310-320等中所述的方法。
本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得该计算机执行如步骤310-320等中所述的方法。
本申请实施例还提供了一种系统，包括前述的终端设备和/或前述的网络设备。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
另外，本申请的各个方面或特征可以实现成方法、装置或使用标准编程和/或工程技术的制品。本申请中使用的术语“制品”涵盖可从任何计算机可读器件、载体或介质访问的计算机程序。例如，计算机可读介质可以包括，但不限于:磁存储器件(例如，硬盘、软盘或磁带等)，光盘(例如，压缩盘(compact disc，CD)、数字通用盘(digital versatile disc，DVD)等)，智能卡和闪存器件(例如，可擦写可编程只读存储器(erasable programmable read-only memory，EPROM)、卡、棒或钥匙驱动器等)。另外，本文描述的各种存储介质可代表用于存储信息的一个或多个设备和/或其它机器可读介质。术语“机器可读介质”可包括但不限于，无线信道和能够存储、包含和/或承载指令和/或数据的各种其它介质。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的 介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (15)

  1. 一种上行接入的方法，其特征在于，包括：
    网络设备接收终端设备在上线时发送的指示信息，所述指示信息用于触发所述网络设备在第一端口发送上行注册窗口指示信息，所述上行注册窗口指示信息用于指示所述终端设备在指示的注册窗口位置发送上行注册信息；
    所述网络设备根据所述指示信息，在所述第一端口发送所述上行注册窗口指示信息。
  2. 根据权利要求1所述的方法，其特征在于，所述网络设备接收终端设备发送的指示信息，包括：
    所述网络设备在所述第一端口的第一通道中接收所述终端设备发送的第一指示信息，所述第一指示信息为与第二通道的频带不同的信号。
  3. 根据权利要求1或2所述的方法，其特征在于，所述网络设备接收终端设备发送的指示信息，包括：
    所述网络设备在所述第一端口的所述第二通道中接收所述终端设备发送的第二指示信息，所述第二指示信息为与所述第二通道的频带相同的信号。
  4. 根据权利要求3所述的方法，其特征在于，当所述第二指示信息为与第二通道现有的握手协议中R-TONES-REQ信号频带相同，但信号形态不同的信号时，所述网络设备根据所述指示信息，在所述第一端口发送所述上行注册窗口指示信息，包括：
    所述网络设备根据所述第一指示信息，在所述第一端口的第一通道中发送所述上行注册窗口指示信息。
  5. 根据权利要求4所述的方法，其特征在于，当所述第二信息为与第二通道现有的握手协议中R-TONES-REQ信号形态相同的信号时，所述方法还包括：
    所述网络设备在所述第一端口的第二通道进行所述握手协议流程。
  6. 一种上行接入的方法，其特征在于，包括：
    终端设备上线时在第二端口向网络设备发送指示信息，所述指示信息用于触发所述网络设备在第一端口发送上行注册窗口指示信息，所述上行注册窗口指示信息用于指示所述终端设备在指示的注册窗口位置发送上行注册信息，所述第二端口与所述网络设备接收所述指示信息的第一端口对应；
    所述终端设备在所述第二端口中接收所述网络设备发送的上行注册窗口指示信息。
  7. 根据权利要求6所述的方法，其特征在于，所述终端设备向网络设备发送指示信息，包括：
    所述终端设备在所述第二端口的第一通道中向所述网络设备发送第一指示信息，所述第一指示信息为与第二通道的频带不同的信号。
  8. 根据权利要求7所述的方法，其特征在于，所述终端设备向网络设备发送指示信息，包括：
    所述终端设备在所述第二端口的第二通道中向所述网络设备发送第二指示信息，所述第二指示信息为与所述第二通道的频带相同的信号。
  9. 根据权利要求8所述的方法，其特征在于，在所述终端设备在所述第二端口的第 二通道中向所述网络设备发送第二指示信息之前，所述方法还包括：
    当终端设备在所述第二通道上侦听到现有的握手协议信号，所述终端设备等待所述握手协议流程完成。
  10. 根据权利要求6至9中任一项所述的方法，其特征在于，所述方法还包括：
    所述终端设备在超时之前在所述第二端口未接收到所述上行注册窗口指示信息的情况下，所述终端设备在所述第二端口的第二通道中向所述网络设备发送所述第二指示信息。
  11. 根据权利要求6至10中任一项所述的方法，其特征在于，在所述终端设备向网络设备发送指示信息之前，所述方法还包括：
    所述终端设备在所述第二端口的第一通道中接收到所述上行注册窗口指示信息的情况下，所述终端设备在指示的注册窗口位置向所述网络设备发送注册信息。
  12. 一种网络设备，其特征在于，所述网络设备包括：存储器、处理器和收发器，
    所述存储器用于存储程序；
    所述处理器用于执行所述存储器中存储的程序，当所述程序被执行时，，所述处理器通过所述收发器执行权利要求1至5中任一项所述的方法。
  13. 一种终端设备，其特征在于，所述网络设备包括：存储器、处理器和收发器，
    所述存储器用于存储程序；
    所述处理器用于执行所述存储器中存储的程序，当所述程序被执行时，，所述处理器通过所述收发器执行权利要求6至11中任一项所述的方法。
  14. 一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行如1至5中任一项所述的方法。
  15. 一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行如6至11中任一项所述的方法。
PCT/CN2018/100012 2018-08-10 2018-08-10 一种上行接入的方法、设备 WO2020029261A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP18929813.6A EP3813300A4 (en) 2018-08-10 2018-08-10 UPLINK ACCESS METHOD AND DEVICE
PCT/CN2018/100012 WO2020029261A1 (zh) 2018-08-10 2018-08-10 一种上行接入的方法、设备
US17/158,119 US11234062B2 (en) 2018-08-10 2021-01-26 Uplink access method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/100012 WO2020029261A1 (zh) 2018-08-10 2018-08-10 一种上行接入的方法、设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/158,119 Continuation US11234062B2 (en) 2018-08-10 2021-01-26 Uplink access method and device

Publications (1)

Publication Number Publication Date
WO2020029261A1 true WO2020029261A1 (zh) 2020-02-13

Family

ID=69415328

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/100012 WO2020029261A1 (zh) 2018-08-10 2018-08-10 一种上行接入的方法、设备

Country Status (3)

Country Link
US (1) US11234062B2 (zh)
EP (1) EP3813300A4 (zh)
WO (1) WO2020029261A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100373946C (zh) * 2003-11-21 2008-03-05 华为技术有限公司 一种授权系统及方法
CN102098593A (zh) * 2011-02-23 2011-06-15 华为技术有限公司 一种epon系统中上行注册的方法和远端设备
WO2015100534A1 (zh) * 2013-12-30 2015-07-09 华为技术有限公司 以太网无源光网络的通信方法、设备和系统
CN106572401A (zh) * 2016-10-11 2017-04-19 烽火通信科技股份有限公司 一种基于软件定义的光接入网系统及其实现方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5790097B2 (ja) * 2011-04-04 2015-10-07 沖電気工業株式会社 加入者側端末装置及び加入者側端末装置の消費電力制御方法
WO2013107015A1 (en) * 2012-01-19 2013-07-25 Telefonaktiebolaget L M Ericsson(Publ) Power over ethernet supervision
US10911254B2 (en) * 2018-06-15 2021-02-02 Maxlinear, Inc. Handshake operation in point-to-multipoint access from distribution point

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100373946C (zh) * 2003-11-21 2008-03-05 华为技术有限公司 一种授权系统及方法
CN102098593A (zh) * 2011-02-23 2011-06-15 华为技术有限公司 一种epon系统中上行注册的方法和远端设备
WO2015100534A1 (zh) * 2013-12-30 2015-07-09 华为技术有限公司 以太网无源光网络的通信方法、设备和系统
CN106572401A (zh) * 2016-10-11 2017-04-19 烽火通信科技股份有限公司 一种基于软件定义的光接入网系统及其实现方法

Also Published As

Publication number Publication date
US20210152899A1 (en) 2021-05-20
EP3813300A1 (en) 2021-04-28
US11234062B2 (en) 2022-01-25
EP3813300A4 (en) 2021-07-28

Similar Documents

Publication Publication Date Title
EP3326391B1 (en) Bluetooth low energy combined listen and scan window
JP6332883B2 (ja) 電力消費を削減するための方法および装置
CN102882938A (zh) 一种数据共享方法及移动终端
WO2020038331A1 (zh) 确定上行资源的方法与装置
JP5414059B2 (ja) 無線通信方法およびシステムならびにその無線通信装置
TWI492656B (zh) 無線存取點
WO2004059994A3 (en) Mobile terminal connecting different terminal equipment te2 at rm interface with a plurality of wireless networks at um interface
EA032516B1 (ru) Система и способ для обеспечения связи в беспроводной сети
CN101667849A (zh) 数据传输方法、网络设备及通信系统
US10601830B2 (en) Method, device and system for obtaining local domain name
JP2012503360A (ja) 無線通信ネットワークにおける高速なローカルアドレス割り当て
CN104581986A (zh) 一种无线连接方法和设备
US20220116269A1 (en) Apparatus and methods for synchronization pattern configuration in an optical network
US20170110885A1 (en) Reverse power supply management method, apparatus and system
WO2018059253A1 (zh) 参考信号发送方法、参考信号处理方法及设备
WO2015127729A1 (zh) 无输入设备接入无线局域网的方法、装置和系统
JP4351289B1 (ja) 加入者宅側通信装置
CN111295868B (zh) 用于建立安全无线连接的方法和设备
WO2020029261A1 (zh) 一种上行接入的方法、设备
CN101141411A (zh) 在无源光网络接入设备上实现用户端口定位的方法
US20120324081A1 (en) Unified Network Architecture Based on Medium Access Control Abstraction Sub-layer
CN113132825B (zh) 一种通信的方法、光网络终端、光线路终端和系统
EP3700157A1 (en) Communication method and device
WO2009041773A3 (en) Communication method and apparatus
WO2023050435A1 (zh) 一种用于无线保真Wi-Fi系统的通信方法及装置

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: 18929813

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018929813

Country of ref document: EP

Effective date: 20210122

NENP Non-entry into the national phase

Ref country code: DE