Abstract: Synchronizing clocks across a Remote PHY network without use of the Precision Time Protocol (PTP). The clock used by the CCAP core may be referred to herein as a slave clock, while the clock used by each RPD may be referred to as a master clock. Time differences between each master clock and a slave clock in the Remote PHY network are tracked. Slave clocks at the core may, but need not, lock to a single RPD master clock. A CCAP core tracks differences in clock values between a singular CCAP core clock and one or more RPD clocks using clock values identified by received DEPI Latency Measurement (DLM) packets and not using Precision Time Protocol (PTP) protocol. The CCAP core determines a particular RPD clock value to use in sending a map message to a particular RPD. The CCAP core then sends a map message to the particular RPD over the network based on the determined particular RPD clock value.

Abstract: Approaches for Converged Cable Access Platform (CCAP) processing. A software-based CCAP environment is executed on one or more physical machines. The software-based CCAP environment is maintained by a plurality of functional blocks that are each implemented in software and perform a specific function supporting the software-based CCAP environment. Each of the plurality of functional blocks performs their specific function asynchronously from each other. A configuration is maintained for the software-based CCAP environment which informs each of the plurality of functional blocks discretely for one or more Data Over Cable Service Interface Specification (DOCSIS) service groups. The configuration may treat one or more Data Over Cable Service Interface Specification (DOCSIS) service groups as a logical unit with respect to their association with each functional block.

Abstract: A helmet includes an impact mitigating structure (100). The impact mitigating structure includes a first inner layer (102), a second outer layer (104) and a reactive layer (105) positioned between the first inner layer and the second outer layer. The reactive layer includes multiple elements (106) held between the first inner layer and second outer layer. The reactive layer is arranged such that, when the second layer is subject to an impact, the multiple elements of the reactive layer are configured to roll to facilitate movement of the first inner layer and the second outer layer with respect to each other.

Abstract: Enhanced parallelism in DOCSIS filter group and Service Flow processing. A plurality of packets that have been transmitted across a computer network are received. A responsive action to be performed against each of the plurality of packets is determined by performing DOCSIS filter group processing on the plurality of packets using a single unified Filter Group table. The single unified Filter Group table comprises a plurality of rules that each define a set of criteria and a particular responsive action to perform against any packet matching the set of criteria for that rule. The plurality of rules in the single unified Filter Group table identify, in their sets of criteria, different Filter Group identifiers (IDs). Thereafter, the responsive action is performed on each of the plurality of packets. A single unified classifier table may also be used to assign a Service Flow to packets with enhanced parallelism.

Abstract: A helmet includes an impact mitigating structure (100). The impact mitigating structure includes a first inner layer (102), a second outer layer (104) and a reactive layer (105) positioned between the first inner layer and the second outer layer. The reactive layer includes multiple elements (106) held between the first inner layer and second outer layer. The reactive layer is arranged such that, when the second layer is subject to an impact, the multiple elements of the reactive layer are configured to roll to facilitate movement of the first inner layer and the second outer layer with respect to each other.

Abstract: Dynamic, seamless management of virtual network function (VNF) in a highly available (HA) environment. An instance management program instantiates software instances in which a plurality of VNFs reside. A type of VNF is a MAC Domain (MD) VNF, which is a virtual network function that implements the DOCSIS CMTS MAC layer for a particular MAC domain. Upon determining that a particular VNF executing within a first software instance managed by an instance management program should be moved to a second software instance, the particular VNF is moved from the first software instance to the second software instance without ceasing operation of any other VNF also executing in the first software instance. A software instance may have both active and standby VNFs comprised therein. Failover operations of a particular VNF may be performed during runtime without ceasing operation of any of software instance or VNF not associated with the failed VNF.

Abstract: Approaches for a machine comprising multiple CPU cores to process packets transmitted within a network using executable software. One or more packets are processing by advancing those packets through a sequence of two or more stage instances. Each stage instance of the sequence of two or more stage instances corresponds to one stage of a sequence of stages. The packets either carry DOCSIS data and/or is transmitted within a Passive Optical Network (PON). The packets may also be either received from the upstream direction or transmitted in the downstream direction. Each stage instance is restricted from being executed by more than one of the multiple CPU cores. Each stage instance can be executed by any one of the multiple CPU cores.

Abstract: Approaches for processing packets transmitted within a Passive Optical Network (PON) using executable software. Processing packets within a PON may be performed by classifying one or more packets, of a plurality of received packets, to a particular PON system component, and then processing the one or more packets classified to the same PON system component on a single physical or virtual processor. The one or more packets may be forwarded between a sequence of one or more software stages. The software stages may each be configured to execute on separate logical cores or on a single logical core.

Abstract: Recovering or restarting an execution instance. In response to detecting that a particular execution instance in which a software application, such as an optical line terminal (OLT) software application or a broadband network gateway (BNG) software application, providing services for a Passive Optical Network (PON) has failed, restarting the execution instance having only downstream service flow classifiers and entries of an access control list for the particular execution instance to support default service flows and/or voice calls. After restarting the execution instance, the configuration of the instance is adjusted over time to add one or more downstream service flow classifiers or access control list entries such that the instance can provide additional services, beyond the initially supported default service flows and voice calls, to optical network units. Required time to register optical network units with the execution instance is advantageously reduced while maintaining quality of service.

Abstract: Helmet (1) comprising: an inner layer (3) comprising an outer surface (3a, 31a) and an outer protective layer (2) arranged on the inner layer (3), the outer protective layer (2) comprising an inner surface (2a) facing the outer surface (3a, 31a) of the inner layer (3), wherein under an impact force having at least a tangential force component along an outer surface of the outer protective layer (2), the outer protective layer (2) is configured to move relative to the opposing outer surface (3a, 31a) of the inner layer (3), wherein the inner surface (2a) of the outer protective layer (2) is separated from the outer surface (3a, 31a) of the inner layer by a plurality of spacers (4, 40) for reducing a mechanical locking between the inner layer (3) and the outer protective layer (2) upon said relative movement of the outer protective layer (2) with respect to the inner layer (3).

Abstract: The invention relates to a helmet (1) comprising: —an energy absorbing layer (4), —an outer protective layer (2), —an intermediate layer (3) arranged between the energy-absorbing layer (4) and the protective layer (2), —one or more connector elements (5) extending from the energy-absorbing layer (4) through one or more openings in the intermediate layer (3) to the protective layer (2) and fixedly attaching the protective layer (2) with the energy-absorbing layer (4).

Abstract: The present invention relates to a helmet (1) comprising: a first layer (10) forming an outer surface of the helmet (1), a second layer (30), and a reactive layer (20) sandwiched between the first layer (10) and the second layer (30), whereby said reactive layer (20) comprises a plurality of rigid balls (2) allowing the first layer (10) to roll upon the second layer (30) as soon as the helmet (1) undergoes an impact of an intensity greater than a predetermined threshold.

Abstract: A helmet includes an impact mitigating structure (100). The impact mitigating structure includes a first inner layer (102), a second outer layer (104) and a reactive layer (105) positioned between the first inner layer and the second outer layer. The reactive layer includes multiple elements (106) held between the first inner layer and second outer layer. The reactive layer is arranged such that, when the second layer is subject to an impact, the multiple elements of the reactive layer are configured to roll to facilitate movement of the first inner layer and the second outer layer with respect to each other.

Abstract: The present invention relates to a helmet comprising an impact mitigating structure, the impact mitigating structure comprising: a first layer; and a second layer; wherein one or more of a material property, a mechanical property and a geometrical property of the impact mitigating structure is arranged to, when the impact mitigating structure is subject to an impact, facilitate at least partial fracturing of the second layer such that at least a portion of the second layer is able to move relative to the first layer.

Abstract: Recovering or restarting an execution instance. In response to detecting that a particular execution instance in which a software application, such as an optical line terminal (OLT) software application or a broadband network gateway (BNG) software application, providing services for a Passive Optical Network (PON) has failed, restarting the execution instance having only downstream service flow classifiers and entries of an access control list for the particular execution instance to support default service flows and/or voice calls. After restarting the execution instance, the configuration of the instance is adjusted over time to add one or more downstream service flow classifiers or access control list entries such that the instance can provide additional services, beyond the initially supported default service flows and voice calls, to optical network units. Required time to register optical network units with the execution instance is advantageously reduced while maintaining quality of service.

Abstract: Recovering or restarting an execution instance. In response to detecting that a particular execution instance, in which a cable modem termination system (CMTS) software application, an optical line terminal (OLT) software application, and/or broadband network gateway (BNG) software application has failed, restarting the execution instance without adding any downstream service flow classifiers to the instance or configuring any entries of an access control list for the instance. After restarting the execution instance, over time adjusting the configuration of the instance to add one or more downstream service flow classifiers or access control list entries such that the instance can provide additional services, beyond a default service flow, to cable modems or optical network units. Support for voice calls may be initially added to the execution instance upon startup.

Abstract: Approaches for processing packets transmitted within a Passive Optical Network (PON) using executable software. Processing packets within a PON may be performed by classifying one or more packets, of a plurality of received packets, to a particular PON system component, and then processing the one or more packets classified to the same PON system component on a single physical or virtual processor. The one or more packets may be forwarded between a sequence of one or more software stages. The software stages may each be configured to execute on separate logical cores or on a single logical core.

Abstract: Approaches for performing all DOCSIS downstream and upstream data forwarding functions using executable software. DOCSIS data forwarding functions may be performed by classifying one or more packets, of a plurality of received packets, to a particular DOCSIS system component, and then processing the one or more packets classified to the same DOCSIS system component on a single CPU core. The one or more packets may be forwarded between a sequence of one or more software stages. The software stages may each be configured to execute on separate logical cores or on a single logical core.

Abstract: The methods and systems described herein can be used for proactively monitoring regulatory compliance within an order management system, and for providing a real-time or near real-time recommendation relating to a subgroup of information containing suspicious attributes of a trade before the trade is executed. As such, market abuse monitoring is integrated with the order management system to provide historical trade data, identify a subgroup of information containing the suspicious attributes, and provide an actionable and contextualized real-time or near real-time recommendation to a compliance officer or other appropriate individual, officer, or office. As such, potential market abuse can be prevented by, for example, a rejection of the trade. By providing proactive surveillance rather than reactive surveillance relating to potential market abuse, fines or other consequences are also prevented. As such, compliance is improved.

Abstract: Scheduling of packets to be forwarded onto DOCSIS downstream channels as part of a Virtual Converged Cable Access Platform (CCAP). A packet to be forwarded onto a DOCSIS downstream channel is enqueued in a service flow queue. The packets stored in the service flow queue are associated with a single service flow. A request is propagated up a hierarchy of schedule elements to a scheduler process to schedule the packet for delivery. The scheduler process determines a grant of how much traffic to offer the DOCSIS downstream channel. The grant determined for the DOCSIS downstream channel may be expressed in units of symbols rather than in bytes. The scheduler process extends a particular grant to the service flow queue by translating symbols in the grant for the service flow queue which issued the request.