Cisco DNCS System Release 2.7 3.7 4.2 テクニカルリファレンス
4038108 Rev A
3
Recommended Practices for DHCT Out-of-Service Assignments
Recommended Practices for DHCT Out-of-Service
Assignments
As stated earlier in this bulletin, Cisco engineers have identified two main scenarios
under which DHCTs are erroneously placed into an administrative state of
out-of-service. They are:
under which DHCTs are erroneously placed into an administrative state of
out-of-service. They are:
Billing systems routinely place DHCTs into an administrative state of
out-of-service to address subscriber non-payment issues.
out-of-service to address subscriber non-payment issues.
Site support staff assigns an administrative state of out-of-service to two-way
DHCTs, then back to in-service two-way, in an attempt to fix various
subscriber-based field issues.
DHCTs, then back to in-service two-way, in an attempt to fix various
subscriber-based field issues.
Cisco engineers offer the following recommendations for system operators to follow
in order to address these two scenarios:
in order to address these two scenarios:
Subscriber Non-Payment
If a subscriber falls into a non-payment condition, system operators should remove
the brick package from that subscriber's DHCT. The brick package, when removed
from a DHCT, removes all services from that DHCT. The subscriber is then forced to
telephone the cable company to correct the issue. The subscriber's DHCT should
remain with an administrative status of two-way while it is in the subscriber's home.
the brick package from that subscriber's DHCT. The brick package, when removed
from a DHCT, removes all services from that DHCT. The subscriber is then forced to
telephone the cable company to correct the issue. The subscriber's DHCT should
remain with an administrative status of two-way while it is in the subscriber's home.
DHCT Troubleshooting
A system operator should avoid assigning a status of out-of-service to a DHCT that is
connected to the headend. However, if the system operator feels that an out-of-service
status MUST be assigned to a DHCT that is in the subscriber's home, then the system
operator MUST follow this action by rebooting the DHCT so that the DHCT releases
the IP address from its non-volatile random access memory (NVRAM). The system
operator must then verify that the reboot request (either manual or remotely) did, in
fact, reset the DHCT. Rebooting the DHCT will remove the IP address from the
physical network, which eliminates the chance of the DHCT creating a future
duplicate IP address issue.
For a DHCT with an administrative status of out-of-service to be handled properly by
the system, that DHCT MUST no longer be in the field and MUST not be "on
account" from a billing system's perspective. A DHCT should NEVER be assigned a
status of out-of-service while still connected to the RF network without being
followed by a reboot.
connected to the headend. However, if the system operator feels that an out-of-service
status MUST be assigned to a DHCT that is in the subscriber's home, then the system
operator MUST follow this action by rebooting the DHCT so that the DHCT releases
the IP address from its non-volatile random access memory (NVRAM). The system
operator must then verify that the reboot request (either manual or remotely) did, in
fact, reset the DHCT. Rebooting the DHCT will remove the IP address from the
physical network, which eliminates the chance of the DHCT creating a future
duplicate IP address issue.
For a DHCT with an administrative status of out-of-service to be handled properly by
the system, that DHCT MUST no longer be in the field and MUST not be "on
account" from a billing system's perspective. A DHCT should NEVER be assigned a
status of out-of-service while still connected to the RF network without being
followed by a reboot.