CN110958280B

CN110958280B - Method for switching auxiliary core device, remote device and computer readable medium

Info

Publication number: CN110958280B
Application number: CN201811125922.XA
Authority: CN
Inventors: 刁克刚
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2018-09-26
Filing date: 2018-09-26
Publication date: 2022-06-14
Anticipated expiration: 2038-09-26
Also published as: CN110958280A

Abstract

Embodiments of the present disclosure provide a communication method, device and computer readable medium for switching a secondary core device. In the communication method, at a remote device, in response to the remote device being to switch from a connected first core device to a second core device, sending a handover request to the second core device, the handover request including information associated with a set of resources managed by the first core device before the handover and managed by the second core device after the handover; and establishing a connection with the second core device in response to receiving a reply from the second core device agreeing to manage the set of resources. Embodiments of the present disclosure improve handover problems caused by messages associated with the handover not including information indicative of a set of resources during a conventional handover procedure.

Description

Method for switching auxiliary core device, remote device and computer readable medium

Technical Field

Embodiments of the present disclosure relate generally to the field of communications, and more particularly, to a method of switching a secondary core device, a remote device, and a computer-readable medium.

Background

A Converged Cable Access Platform (CCAP) core device includes a Cable Modem Termination System (CMTS) core device for Data Over Cable Service Interface Specification (DOCSIS) and an Edge Quadrature Amplitude Modulation (EQAM) core device for video. The CMTS core devices contain DOCSIS MAC and upper layer DOCSIS protocols. The EQAM core device contains all the video processing functions currently provided by the EQAM.

The Remote Physical Device (RPD) is a physical layer converter that converts downstream DOCSIS, Moving Picture Experts Group (MPEG) video and out of band (OOB) signals received from a CCAP core device on a digital medium such as ethernet or a passive optical network into analog signals for transmission over a Radio Frequency (RF) or linear optical system. And on the other hand, upstream DOCSIS and OOB signals received from analog media such as RF or linear optics are converted into digital signals for transmission to the CCAP core device over ethernet or PON. The RPD has a resource set List (ResourceSet List) that identifies which secondary core devices can control which RPD object.

The RPD establishes connection with both CCAP main core equipment and at least one CCAP auxiliary core equipment. When the RPD is handed over from a first secondary core device (active core device) connected to it to a second secondary core device (standby core device), the corresponding resource set list that was originally managed by the first secondary core device is also handed over to the second secondary core device. However, the corresponding resource set list originally managed by the first secondary core device is not specified in the conventional handover message, so that when the RPD is restored with the first secondary core device and a handover back to the first secondary core device is desired, the corresponding resource set list originally managed by the first secondary core device cannot be returned to the first secondary core device.

Disclosure of Invention

Embodiments of the present disclosure relate to a method of switching a secondary core device, a remote device, and a computer readable medium.

In a first aspect of the disclosure, a method of communication is provided. The method comprises the following steps: at a remote device, in response to the remote device being to switch from a connected first core device to a second core device, sending a handover request to the second core device, the handover request including information associated with a set of resources managed by the first core device prior to the handover and managed by the second core device after the handover; and in response to receiving a reply from the second core device agreeing to manage the set of resources, establishing a connection with the second core device.

In a second aspect of the disclosure, a method of communication is provided. The method comprises the following steps: receiving, at a core device, a handover request from a remote device in response to the remote device being to handover from another core device to the core device to which it is connected, the handover request indicating that the remote device is to handover from a connection with another core to a connection with the core device, the handover request including information associated with a set of resources managed by the other core device before the handover and managed by the core device after the handover; and sending a response to the remote device agreeing to manage the set of resources to cause the remote device to establish a connection with the core device.

In a third aspect of the disclosure, a remote device is provided. The remote device includes at least one processor and at least one memory including computer program instructions. The at least one memory and the computer program instructions are configured to, with the at least one processor, cause the remote device to perform the method of the first aspect of the disclosure.

In a fourth aspect of the disclosure, a core device is provided. The core device includes at least one processor and at least one memory including computer program instructions. The at least one memory and the computer program instructions are configured to, with the at least one processor, cause the core device to perform the method of the second aspect of the disclosure.

In a fifth aspect of the disclosure, a computer-readable medium is provided. The computer readable medium comprises machine executable instructions which, when executed, cause a machine to perform a method according to the first aspect.

In a sixth aspect of the disclosure, a computer-readable medium is provided. The computer readable medium comprises machine executable instructions which, when executed, cause a machine to perform a method according to the second aspect.

It should be understood that the statements herein reciting aspects are not intended to limit the critical or essential features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The above and other objects, features and advantages of the embodiments of the present disclosure will become readily apparent from the following detailed description read in conjunction with the accompanying drawings. Several embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:

fig. 1 illustrates a schematic diagram of a communication system in which embodiments of the present disclosure may be implemented.

Fig. 2 shows a schematic diagram of a process 200 of a communication method according to an embodiment of the disclosure.

Fig. 3 shows a flow diagram of a communication method 300 according to an embodiment of the present disclosure.

Fig. 4 shows a flow diagram of a communication method 400 according to an embodiment of the present disclosure.

Fig. 5 illustrates a simplified block diagram of a device suitable for implementing embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numerals are used to designate the same or similar components.

Detailed Description

The principles and spirit of the present disclosure will be described with reference to a number of exemplary embodiments shown in the drawings. It is understood that these specific embodiments are described merely to enable those skilled in the art to better understand and implement the present disclosure, and are not intended to limit the scope of the present disclosure in any way.

As used herein, the terms "includes," including, "and the like are to be construed as open-ended inclusions, i.e.," including, but not limited to. The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first," "second," and the like may refer to different or the same object. Other explicit and implicit definitions are also possible below.

As used herein, the term "determining" encompasses a wide variety of actions. For example, "determining" can include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Further, "determining" can include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. Further, "determining" may include resolving, selecting, choosing, establishing, and the like.

The term "circuitry" as used herein refers to one or more of the following: (a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry); and (b) a combination of hardware circuitry and software, such as (if applicable): (i) a combination of analog and/or digital hardware circuitry and software/firmware, and (ii) any portion of a hardware processor and software (including a digital signal processor, software, and memory that work together to cause an apparatus, such as an OLT or other computing device, to perform various functions); and (c) hardware circuitry and/or a processor, such as a microprocessor or a portion of a microprocessor, that requires software (e.g., firmware) for operation, but may be software-free when software is not required for operation.

The definition of circuit applies to all usage scenarios of this term in this application, including any claims. As another example, the term "circuitry" as used herein also covers an implementation of merely a hardware circuit or processor (or multiple processors), or a portion of a hardware circuit or processor, or software or firmware accompanying it. For example, the term "circuitry" would also cover a baseband integrated circuit or processor integrated circuit or a similar integrated circuit in an OLT or other computing device, as applicable to the particular claim element.

Fig. 1 illustrates a schematic diagram of a communication system 100 in which embodiments of the present disclosure may be implemented. As shown in fig. 1, communication system 100 may include a remote device 110 connected to a core device 120-1 through a communication link 112. In addition, remote device 110 is connected to core device 120-2 via communication link 113 and to further core device 120-3 via further communication links (not shown), and so on. In some embodiments,

communication links

112 and 113, etc. between remote device 110 and core device 120 may include a Converged Interconnect Network (CIN).

The term "core device" in this disclosure relates to a Converged Cable Access Platform (CCAP) core device, which includes a Cable Modem Termination System (CMTS) core device for Data Over Cable Service Interface Specification (DOCSIS) and an Edge Quadrature Amplitude Modulation (EQAM) core device for video. The CMTS core devices contain DOCSIS MAC and upper layer DOCSIS protocols. This includes all signaling functions, downstream and upstream bandwidth scheduling and DOCSIS framing. The DOCSIS functionality of the CMTS core device is defined by mulpev 3.0. The EQAM core device contains all the video processing functions currently provided by the EQAM.

The term "remote device" refers in this disclosure to a remote physical device (hereinafter also referred to as "RPD"). RPD is a physical layer converter that can consist in, on the one hand, converting downstream DOCSIS, Moving Picture Experts Group (MPEG), video and Out Of Band (OOB) signals received from CCAP core devices over digital media such as Ethernet or Passive Optical Networks (PON) into analog signals for transmission over Radio Frequency (RF) or linear optical systems.

The modular front end architecture version 2(MHAv2) architecture allows multiple RPDs to be managed by more than one CCAP core device. The RPD is controlled by one active primary CCAP core device and zero or more active secondary CCAP core devices. The active master CCAP core device is the final controlling entity of the RPD. The active master CCAP core device controls RPD, resource allocation, software upgrade and reset or restart operations. The secondary CCAP core device manages a subset of RPD resources, such as a particular channel or RF port. Each secondary CCAP core device establishes its own Generic Control Plane (GCP) session and layer two tunneling protocol version 3(L2TPv3) control session with the RPD.

Potential secondary CCAP core devices include, but are not limited to, the following: the broadcast EQAM CCAP core device controls only the downstream video broadcast channel; SCTE 55-1 and SCTE 55-2CCAP core devices provide traditional Set-Top-Box (STB) control; the CCAP core equipment of the narrow-cast EQAM controls a downstream video narrow-cast channel only; a "forward OOB" CCAP core device that controls and acquires NDF, typically broadcasting to multiple RPD ports; a "reverse OOB" CCAP core device that controls and receives the NDR channel, one for each RPD port; a CMTS CCAP to control downstream and upstream channels of the individual MAC domains; CMTS core devices are programmed or configured in a vendor specific manner to operate as primary or secondary core devices.

The core devices may have different roles, such as active primary core devices, standby core devices, DOCSIS core devices, EQAM core devices, and the like. The specific role of each core device is determined during the GCP configuration phase.

For example, in the example depicted in fig. 1, core device 120-1 may be the primary core device of remote device 110, i.e., the ultimate controlling entity of remote device 110. The core devices 120-2 through 120-3 may act as secondary core devices for the remote device 110, and they may manage a subset of the remote device 110 resources, e.g., a particular channel or RF port, etc. In the context of the present disclosure, primary core device 120-1 and secondary core devices 120-2 through 120-3 may be collectively referred to as core device 120.

It should be appreciated that although fig. 1 depicts communication network 100 as having a particular number of remote devices 110 and core devices 120, which communicate via a

particular communication link

112 and 113, in other embodiments, communication network 100 may have any number of remote devices and core devices, which may communicate using any suitable communication link in any suitable manner.

The GCP connection between remote device 110 and secondary core devices 120-2 through 120-3 may fail for a variety of reasons, including failure of the secondary core devices themselves. In the event of a failure of the currently active secondary core device (e.g., secondary core device 120-2), the GCP connection needs to be switched to the designated standby secondary core device (e.g., secondary core device 120-3). The GCP handover procedure may be initiated by the remote device 110 or the core device (any of 120-1 to 120-3). For example, if a currently active secondary core device (e.g., secondary core device 120-2) requires a maintenance window, the operator may wish to initiate a GCP handover procedure from secondary core device 120-2.

To do so, the remote device 110 must implement a CCAP core device identification "CCAP core identity" table that identifies the CCAP core device owner for the resource set, the role of the CCAP core device (whether it is the primary CCAP core device), the mode of the CCAP core device (active core device, standby core device, core device to connect to, etc.), and a candidate standby core device table.

In addition, the remote device 110 must implement a resource set (ResourceSet) list that identifies which secondary core devices can control which remote device object. A set of resources consists of a series of channels from beginning to end on a particular RF port.

To support the GCP handover procedure, the remote device 110 defines the following messages:

handover notification ": during the GCP handoff, the RPD will generate a notification to the standby core device indicating that it wishes to take over for the failed core device. In the handover notification message, the RPD must include the following attributes: the RPD identity identifies "RpdIdentification", the device location "DeviceLocation", as well as the core device identification (core id) of the failed core device "OosCore" and the standby core device, i.e. the newly active core device "NewActiveCore". The RPD must set the message status to zero. The RPD must set the notification type as the handover notification. The attributes and contents in the handover notification are shown in table 1 below:

table 1: switching attributes and content in notifications

Secondary core device GCP status notification "auxcoregcpts notify": when the state of the GCP connection with the secondary core device changes, the RPD generates a notification message to the active primary core device. The RPD must include the following attributes: and the auxiliary core device GCP state notification comprises an auxiliary core device identifier 'AuxCoreId' and an auxiliary core device IP address 'AuxCoreIpAddress'. The RPD must set the message status to zero. The RPD must set the notification type to the secondary core device GCP status notification. The RPD must set the auxiliary core device GCP connection status "auxcoregconnectionstatus" to a state corresponding to the current connection state of the auxiliary core device. The RPD must set the secondary core device identity to the core device identity informing the secondary core device to which it belongs. The RPD must set the secondary core device IP address to inform the IP address of the secondary core device to which it belongs. The attributes and contents in the secondary core device GCP status notification are shown in table 2 below:

table 2: attribute and content in secondary core device GCP status notifications

GCP handover control format "gcpmandovercontrol TLV": the CCAP core device uses the GCP handover control format to request the RPD to initiate a handover from one core device to another core device, where the following attributes are defined: GCP handover control "gcpmandovercontrol", gcphndovercontrolaction "gcphanedonto-ControlAction", faulty core device "OosCore", standby core devices, that is, newly active core device "NewActiveCore" and layer two tunneling protocol version 3 "L2 TPv 3". The attributes and contents in the GCP handover control format are shown in table 3 below:

table 3: properties and content in GCP switch control format

The standby core device GCP replies "coregpbacackupresponse TLV": the CCAP core device uses this attribute to accept or reject the handover request from the RPD. Reading this attribute always returns a no action value. The attributes and contents in the standby core device GCP response format are shown in table 4 below:

table 4: properties and content in alternate core device GCP response Format

According to current specifications of remote devices, the remote device may have multiple sets of resources, and each set of resources may be owned by either an active secondary core device or a standby secondary core device. However, current GCP handover mechanisms do not support resource set level handover because no resource set information is exchanged during GCP handover.

For example, when remote device 110 switches from a first secondary core device (currently active core device, e.g., core device 120-2) to which it is connected to a second secondary core device (standby core device, e.g., core device 120-3), the corresponding resource set list that would otherwise be managed by core device 120-2 is also handed over to core device 120-3. However, the corresponding resource set list managed by core device 120-2 is not described in the conventional handover message, so that when remote device 110 attempts to reconnect with core device 120-2 and wants to switch back to core device 120-2, the corresponding resource set list originally managed by core device 120-2 cannot be returned to core device 120-2. Thus, upon a GCP handover, all resource sets in the remote device 110 will be managed only by the active secondary core devices. It will prevent the CCAP secondary core device approach to design run (Active-Active) Active-Active mode.

In view of the above-mentioned problems, as well as other potential problems, existing in conventional approaches, embodiments of the present disclosure provide a method, remote device, and computer-readable medium for switching a secondary core device. Through the embodiment of the disclosure, the remote device can use a uniform framework to cover all the switched auxiliary core device scenes, and then can use different switched auxiliary core device schemes for different scenes based on the framework. When a certain scenario of switching the auxiliary core devices occurs, the remote device triggers the scheme of switching the auxiliary core devices. In addition, the core device may also trigger switching of the secondary core device scheme. Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

The principles and implementations of the present disclosure will be described in detail below with reference to fig. 2, where fig. 2 illustrates a process 200 according to an example embodiment of the present disclosure. For discussion purposes, process 200 will be described with reference to fig. 1. Process 200 may involve a handover of a secondary core device.

Taking the remote device 110 in fig. 1 as an example, it may have a core device identification list describing the core devices associated with it, which is shown in table 5 below:

table 5: core device identification list for remote device 110

As shown in Table 5, resource sets 1 and 2 belong to remote device 110. Core device 120-2 is a secondary core device and has resource set 1, and core device 120-3 is a standby for core device 120-2. Core device 120-3 is a secondary core device and has resource set 2, and core device 120-2 is a standby device for core device 120-3.

The remote device 110 also has a resource set table, shown in table 6 below:

resource set indexing	To which CCAP core device a set of resources belongs
		1	Core device 120-2
2	Core device 120-3

Table 6: resource set table for remote device 110

In the initial phase, the core devices 120-2 and 120-3 operate in Active-Active mode and both employ DOCSIS functionality to process resource set 1 and resource set 2, respectively.

On the premise that the remote device 110 is connected to the core device 120-2, if the remote device 110 detects a failure in the connection to the core device 120-2, for example due to a failure of the core device 120-2 itself, a handover procedure of the remote device 110 will be triggered.

According to conventional methods, the remote device 110 issues a handover request, which may be, for example, the aforementioned "handover notification", to the standby core device 120-3 of the core device 120-2. The handover request may include the information listed in table 7, according to table 1 already listed:

properties	Content providing method and apparatus
		RpdIdentification	Remote device	110
DeviceLocation	Location of remote device 110 listed in TLV format
		OosCore	10
NewActiveCore	11

Table 7: content of the handover request of the remote device 110

If the core device 120-3 approves the handoff request from the remote device 110, the remote device 110 will send a reply "REX write W/CoreGcPBacackupResponse" approving the handoff request. After the core device 120-3 has configured the remote device 110 accordingly, the remote device 110 sends a notification, such as the "auxCoreGcPStatusNotify" mentioned above, to the core device 120-1 to notify the core device 120-1 that the core device 120-3 becomes an active core device. According to table 2 shown above, the secondary core device GCP status notification at this time can be shown by table 8:

table 8: secondary core device GCP status notification for remote device 110

After this handover, the resource set table is shown in table 9:

resource set indexing	To which CCAP core device a set of resources belongs
		1	Core device 120-3
2	Core device 120-3

Table 9: resource set table of switched remote device 110

At this point, resource sets 1 and 2 are both managed by core device 120-3. If the core device 120-2 is removed from the failure and the remote device 110 wants to recover the connection with the core device 120-2, the core device 120-2 should take over the originally managed resource sets again according to the above-mentioned rule that the resource sets of the remote device 110 are managed by the corresponding core devices respectively. However, since the resource set table of the switched remote device 110 only indicates that resource sets 1 and 2 are now both managed by the core device 120-3. Thus, remote device 110 does not know which set of resources should be re-switched to core device 120-2. In other words, there is no information describing aspects about the resource set in the previous handover procedure. Thereby, the operation mode between the remote device 110 and the core devices 120-2 and 120-3 before the handover process is no longer restored. Accordingly, embodiments of the present disclosure propose to add information describing resource sets to the conventional handover signaling.

As shown in fig. 2, once the handover procedure is triggered, that is, the remote device is to handover from the connected core device 120-2 to the core device 120-3, the remote device 110 sends 220 a handover request to the core device 120-3. Information associated with the set of resources managed by core device 120-2 prior to the handover and core device 120-3 after the handover is included in the handover request.

In some embodiments, the information "ResourceSetList TLV" used to describe the set of resources may be as shown in table 10:

table 10: information for describing resource collections

In some embodiments, a handover request is added with information describing the resource set, i.e., "handover notify" may be represented in table 11:

table 11: properties and content of new handover request

The handover request includes a set of resources to be handed over from core device 120-2 to core device 120-3 according to the contents of the new handover request of remote device 110 shown in table 11.

In some embodiments, the remote device 110 may detect that the connection with the core device 120-2 has failed and send the handover request to the core device 120-2.

In some embodiments, the handover procedure may be triggered by either core device. In this case, the core device 120-2 sends 210 handover control information for the generic control plane to the remote device 110, in which information associated with the set of resources of the core device 120-2 is indicated. For example, the resource set of core device 120-2 will be handed over to the target core device in the handover process, i.e., core device 120-3.

In some embodiments, the handover control information of the generic control plane, which is added with information indicating the resource set, i.e., "gcpnandovercontrol TLV" may be represented in table 12:

table 12: properties and content in a new GCP switch control format

With continued reference to fig. 2, once the core device 120-3 accepts the handoff request of the remote device 110, a reply is sent 230 to the remote device 110 agreeing to the handoff. The response includes information agreeing to manage the set of resources of the original core device 120-2.

In some embodiments, a standby core device GCP reply, i.e., "coregpackupresponse TLV," incorporating information indicating an agreement to manage the set of resources of the original core device may be represented in table 13:

table 13: properties and content in new standby core GCP response Format

In some embodiments, once the handover request is accepted by the core device 120-3, the remote device 110 may send 240 a message to the core device 110-1 indicating that the set of resources is managed by the core device 120-3. This message may be, for example, the above-mentioned secondary core device GCP status notification, i.e. "auxcordgcpttatustnotify".

In some embodiments, the addition of a message indicating that the resource set is managed by the core device may be represented in table 14:

table 14: properties and content in new secondary core device GCP status notifications

Referring again to fig. 2, once the remote device 110 completes the handoff process described above, a connection is established 250 with the core device 120-3.

Fig. 3 shows a flow diagram of a communication method 300 according to an embodiment of the present disclosure. In some embodiments, the method 300 may be implemented by a remote device 110 in the communication network 100, for example, may be implemented by a processor or processing unit of the remote device 110. In other embodiments, the method 300 may also be implemented by a computing device separate from the remote device 110, or may be implemented by other elements in the communication network 100. For ease of discussion, the method 300 will be discussed in conjunction with FIG. 1.

At 310, if the remote device 110 is to be handed over from the core device 120-2 to the core device 120-3, a handover request is sent to the core device 120-3, the handover request including information associated with a set of resources managed by the core device 120-2 before the handover and managed by the core device 120-3 after the handover.

In some embodiments, the handover request is sent to core device 120-3 if remote device 110 detects a failure of the connection with core device 120-2.

In some embodiments, the handover request is sent to core device 120-3 if remote device 110 receives a message from core device 120-2 indicating the set of resources.

At 320, if the remote device 110 receives a reply from the core device 120-3 agreeing to manage the set of resources, a connection is established with the core device 120-2.

In some embodiments, the remote device 110 may also send a message to a common management device of the core device 120-2 and the core device 120-3 (core device 120-1) indicating that the set of resources is managed by the core device 120-3.

In some embodiments, core device 120-2 and core device 120-3 are secondary core devices that are converged to a cable access platform CCAP, and core device 120-1 is a primary core device of the CCAP.

Fig. 4 shows a flow diagram of a communication method 400 according to an embodiment of the present disclosure. In some embodiments, the method 300 may be implemented by the core device 120 in the communication network 100, for example, may be implemented by a processor or processing unit of the core device 120. In other embodiments, the method 400 may also be implemented by a computing device separate from the core device 120, or may be implemented by other elements in the communication network 100. For ease of discussion, the method 400 will be discussed in conjunction with FIG. 1.

At 410, if the remote device 110 is to be handed over from the core device 120-2 to the core device 120-3, the core device 120-3 receives a handover request from the remote device 110, the handover request including information associated with a set of resources managed by the core device 120-2 before the handover and managed by the core device 120-3 after the handover.

In some embodiments, core device 120-3 receives a handoff request from remote device 110 if remote device 110 detects a failure of the connection with core device 120-2.

In some embodiments, if the remote device 110 receives a message from the core device 120-2 indicating the set of resources, the core device 120-3 receives a handover request from the remote device 110.

At 420, the core device 120-3 sends a reply to the remote device 110 agreeing to manage the set of resources to cause the remote device 110 to establish a connection with the core device 120-3.

In some embodiments, core device 120-2 and the core device 120-3 are secondary core devices of a CCAP.

In some embodiments, an apparatus (e.g., remote device 110) capable of performing method 400 may include respective means for performing the steps of method 400. These components may be implemented in any suitable manner. For example, it may be implemented by a circuit or a software module.

In some embodiments, the apparatus comprises: means for sending a handover request to a second core device in response to the remote device being to handover from a connected first core device to the second core device, the handover request including information associated with a set of resources managed by the first core device before the handover and managed by the second core device after the handover. The apparatus also includes means for establishing a connection with the second core device in response to receiving an acknowledgement from the second core device agreeing to manage the set of resources.

In some embodiments, the means for sending the handover request to the second core device may include means for sending the handover request to the second core device in response to detecting a failure of the connection of the remote device to the first core device.

In some embodiments, the means for sending the handover request to the second core device may include means for sending the handover request to the second core device in response to receiving a message from the first core device indicating the set of resources.

In some embodiments, the apparatus may further include means for sending a message to a common management device of the first core device and the second core device indicating that the set of resources is managed by the second core device.

In some embodiments, the first core device and the second core device are secondary core devices of a CCAP converged cable access platform, and the common management device is a primary core device of the CCAP.

In some embodiments, an apparatus (e.g., remote device 120-3) capable of performing method 500 may include corresponding means for performing the various steps of method 500. These components may be implemented in any suitable manner. For example, it may be implemented by a circuit or a software module.

In some embodiments, the apparatus includes means for receiving a handover request from a remote device in response to the remote device being to handover from another core device to which it is connected to the core device. The handover request indicating that the remote device is to switch from a connection with another core to a connection with the core device, the handover request including information associated with a set of resources managed by the other core device before the handover and managed by the core device after the handover. The apparatus also includes means for sending a reply to the remote device agreeing to manage the set of resources to cause the remote device to establish a connection with the core device.

In some embodiments, the means for receiving the handover request may include means for receiving the handover request in response to the remote device detecting that the connection of the remote device with the other core device failed.

In some embodiments, the means for receiving the handover request may include means for receiving the handover request in response to the remote device receiving a message from the other core device indicating the set of resources.

In some embodiments, the core device and the another core device are a converged cable access platform CCAP secondary core device.

Embodiments of the present disclosure improve upon the problem of handover due to messages associated with the handover not including information indicative of a set of resources during a conventional handover procedure. According to this solution, after the handover procedure, once the remote device wants to restore the connection with the prokaryotic core device, the core device is able to obtain information associated with the set of resources it is managing originally.

Fig. 5 illustrates a simplified block diagram of a device 500 suitable for implementing embodiments of the present disclosure. In some embodiments, device 500 may be used to implement remote devices, such as remote device 110 and core device 120 shown in fig. 1.

As shown in fig. 5, the device 500 includes a controller 510. The controller 510 controls the operation and functions of the device 500. For example, in certain embodiments, controller 510 may perform various operations by way of instructions 530 stored in memory 520 coupled thereto.

The memory 520 may be of any suitable type suitable to the local technical environment and may be implemented using any suitable data storage technology, including but not limited to semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems. It will be appreciated that although only one memory 520 is illustrated in FIG. 5, many physically distinct memory units may be present in the device 500.

The controller 510 may be of any suitable type suitable to the local technical environment, and may include, but is not limited to, one or more of general purpose computers, special purpose computers, microcontrollers, digital signal controllers (DSPs), and controller-based multi-core controller architectures. The device 500 may also include a plurality of controllers 510. The controller 510 is coupled to a transceiver 540, which transceiver 540 may facilitate the reception and transmission of information by way of one or more antennas 550 and/or other components.

When device 500 is acting as remote device 110 or core device 120, controller 510, memory 520, instructions 530, and transceiver 540 may cooperate to implement

methods

300 and 400 described above with reference to fig. 3-4. All of the features described above with reference to fig. 2-4 apply to the apparatus 500 and are not described in detail herein.

It should be noted that the embodiments of the present disclosure can be realized by hardware, software, or a combination of software and hardware. The hardware portion may be implemented using dedicated logic; the software portions may be stored in a memory and executed by a suitable instruction execution system, such as a microprocessor or specially designed hardware. Those skilled in the art will appreciate that the apparatus and methods described above may be implemented using computer executable instructions and/or embodied in processor control code, such code being provided, for example, in programmable memory or on a data carrier such as an optical or electronic signal carrier.

By way of example, embodiments of the disclosure may be described in the context of machine-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or split between program modules as described. Machine-executable instructions for program modules may be executed within local or distributed devices. In a distributed facility, program modules may be located in both local and remote memory storage media.

Computer program code for implementing the methods of the present disclosure may be written in one or more programming languages. These computer program codes may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the computer or other programmable data processing apparatus, cause the functions/acts specified in the flowchart and/or block diagram block or blocks to be performed. The program code may execute entirely on the computer, partly on the computer, as a stand-alone software package, partly on the computer and partly on a remote computer or entirely on the remote computer or server.

In the context of the present disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus or processor to perform various ones of the processes and operations described above. Examples of a carrier include a signal, computer readable medium, and the like. Examples of signals may include electrical, optical, radio, acoustic, or other forms of propagated signals, such as carrier waves, infrared signals, and the like.

The computer readable medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. More detailed examples of a computer-readable storage medium include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical storage device, a magnetic storage device, or any suitable combination thereof.

Further, while the operations of the methods of the present disclosure are depicted in the drawings in a particular order, this does not require or imply that these operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Rather, the steps depicted in the flowcharts may change the order of execution. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions. It should also be noted that the features and functions of two or more devices according to the present disclosure may be embodied in one device. Conversely, the features and functions of one apparatus described above may be further divided into embodiments by a plurality of apparatuses.

While the present disclosure has been described with reference to several particular embodiments, it is to be understood that the disclosure is not limited to the particular embodiments disclosed. The disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A method of communication, comprising:

at a remote device, in response to the remote device being to switch from a connected first core device to a second core device, sending a handover request to the second core device, the handover request including information associated with a set of resources managed by the first core device before the handover and managed by the second core device after the handover, the information associated with the set of resources including information describing the set of resources; and

establishing a connection with the second core device in response to receiving a reply from the second core device agreeing to manage the set of resources.

2. The method of claim 1, wherein sending a handover request to the second core device comprises:

sending the handover request to the second core device in response to detecting a failure of the connection of the remote device to the first core device.

3. The method of claim 1, wherein sending a handover request to the second core device comprises:

sending the handover request to the second core device in response to receiving a message from the first core device indicating the set of resources.

4. The method of claim 1, further comprising:

sending a message to a common management device of the first core device and the second core device indicating that the set of resources is managed by the second core device.

5. The method of claim 4, wherein the first core device and the second core device are secondary core devices of a Converged Cable Access Platform (CCAP), and the common management device is a primary core device of the CCAP.

6. A method of communication, comprising:

receiving, at a core device, a handover request from a remote device in response to the remote device being to handover from another core device to which it is connected to the core device, the handover request indicating that the remote device is to handover from a connection with another core device to a connection with the core device, the handover request including information associated with a set of resources managed by the other core device before the handover and managed by the core device after the handover, the information associated with the set of resources including information describing the set of resources; and

sending a reply to the remote device agreeing to manage the set of resources to cause the remote device to establish a connection with the core device.

7. The method of claim 6, wherein receiving the handover request comprises:

receiving the handover request in response to the remote device detecting that the connection of the remote device with the other core device fails.

8. The method of claim 6, wherein receiving the handover request comprises:

receiving the handover request in response to the remote device receiving a message from the other core device indicating the set of resources.

9. The method of claim 6, wherein the core device and the another core device are Converged Cable Access Platform (CCAP) secondary core devices.

10. A remote device, comprising:

at least one processor; and

at least one memory including computer program instructions, the at least one memory and the computer program instructions configured to, with the at least one processor, cause the remote device to:

at a remote device, in response to the remote device being to switch from a connected first core device to a second core device, sending a handover request to the second core device, the handover request including information associated with a set of resources managed by the first core device before the handover and managed by the second core device after the handover, the set of resources associated information including information describing the set of resources; and

11. The remote device of claim 10, wherein the at least one memory and the computer program instructions are further configured to, with the at least one processor, cause the remote device to:

in response to detecting that the connection of the remote device to the first core device fails, sending the handover request to the second core device.

12. The remote device of claim 10, wherein the at least one memory and the computer program instructions are further configured to, with the at least one processor, cause the remote device to:

in response to receiving a message from the first core device indicating the set of resources, sending the handover request to the second core device.

13. The remote device of claim 10, wherein the at least one memory and the computer program instructions are further configured to, with the at least one processor, cause the remote device to:

14. The remote device of claim 13, wherein the first core device and the second core device are secondary core devices that are Converged Cable Access Platform (CCAP), and the common management device is a primary core device of the CCAP.

15. A core device, comprising:

at least one processor; and

at least one memory including computer program instructions, the at least one memory and the computer program instructions configured to, with the at least one processor, cause the core device to:

receiving a handover request from a remote device in response to the remote device being to handover from another core device to which it is connected to the core device, the handover request indicating that the remote device is to handover from a connection with another core device to a connection with the core device, the handover request including information associated with a set of resources managed by the other core device before the handover and managed by the core device after the handover, the information associated with the set of resources including information describing the set of resources; and

16. The core device of claim 15, wherein the at least one memory and the computer program instructions are further configured to, with the at least one processor, cause the core device to:

17. The core device of claim 15, wherein the at least one memory and the computer program instructions are further configured to, with the at least one processor, cause the core device to:

18. The core device of claim 15, wherein the core device and the another core device are Converged Cable Access Platform (CCAP) secondary core devices.

19. A computer readable medium comprising machine executable instructions which, when executed, cause a machine to perform the method of any one of claims 1-5.

20. A computer readable medium comprising machine executable instructions which, when executed, cause a machine to perform the method of any one of claims 6-9.