Abstract: A method and apparatus for analyzing mobile services delivery to provide a coherent path based awareness of the mobile services and the corresponding underlying transport elements supporting each service or path. In various embodiments configuration information status information and connections information associated with elements within a network such as a Long Term Evolution (LTE) wireless network are used to help infer or determine the connections between network elements to be managed.
METHOD AND APPARATUS FOR ANALYZING MOBILE SERVICES
DELIVERY
CROSS REFERENCE TO RELATED APPLICATIONS
This application is related to simultaneously filed United States Patent
Applications Serial No. 12/696,425 (Attorney Docket No. ALU/ 806271 .entitled
"Method and Apparatus for Auditing 4G Mobility Networks"), Serial No.
12/696,642 (Attorney Docket No. ALU/806254, entitled "Method and
Apparatus for Tracing Mobile Sessions"), and Serial No. 12/696,520 (Attorney
Docket No. ALU/806290, entitled "Method and Apparatus for Managing
Mobile Resource Usage"), all of which are herein incorporated by reference in
their respective entireties.
FIELD OF THE INVENTION
The invention relates generally to the field of communication network
management and, more specifically but not exclusively, to management of
wireless communication networks.
BACKGROUND
Fourth Generation (4G) wireless networks support large numbers of
wireless subscribers running one or more applications wherein traffic, is
packetized and transported via IP networks according to multiple network
elements utilizing different transport technologies and applied quality-ofservice
(QoS) policies. Such networks are inherently complex and present
new challenges to network service providers and the network management
tools they rely upon to ensure consistent delivery of high-quality services to
their mobile subscribers.
Existing network management systems used within the context of,
illustratively, network operations centers (NOCs) provide a visualization or
blueprint of a deployed network that can be graphically manipulated by the
user. Specifically, the user may select a network element to gradually expand
network element into at least some of its constituent sub-elements to identify
specific components to query or otherwise process, such as a pass/fail query
or other management level query adapted to ascertain whether or not the
specific components are functioning properly.
While useful, existing network management systems require significant
human knowledge of the network topology and likely sources of failure or
operational degradation.
Specifically, presented with an undesired operational mode, a skilled
operator or user in the NOC may understand what type of elements or subelements
within the network are likely the cause of the undesired operational
mode. Knowing this and knowing the blueprint of the deployed network, the
skilled operator or user can drill down via a graphical user interface to identify
elements or subelements associated with the undesired operational mode.
By sending status update messages and other management-level queries to
these element and sub-elements, a skilled operator or user ascertains which
elements or sub-elements are associated with the undesired operational
mode. The skilled operator or user can then address the undesired
operational mode by rerouting traffic, issuing a repair order for degraded or
damaged equipment and so on.
Unfortunately, few have the necessary knowledge or skills for this task.
Further, it is seen to be desirable to assist operators in some tasks and to
automatically perform other tasks where practicable.
SUMMARY
These and various other deficiencies of the prior art are addressed by
a method and apparatus for analyzing mobile services delivery to provide a
coherent, path-based awareness of the mobile services and the
corresponding underlying transport elements supporting each service or path.
In one embodiment, a method for managing a network including a
plurality of network elements comprises retrieving, for each of the network
elements to be managed within the network, respective configuration
information, status information and connections information; determining,
using the retrieved information, at least a portion of the connections by which
data is communicated between the network elements to be managed; and
storing, in a computer readable storage medium, data representing at least a
portion of the retrieved network element information and determined network
element connections.
Additional embodiments provide for identifying the elements within the
network that are necessary to support each of a plurality of mobile services,
the necessary elements including at least managed network elements and
communications links. The mobile services may comprise Evolved Packet
Solution (EPS) related paths. The connections information may include
address information associated with one or both of packets received by a
network element and packets transmitted by the network element.
Determining connections may comprise inferring that a connection exists
between two network elements using packet address information, which may
be iteratively performed for each of the managed network elements.
BRIEF DESCRIPTION OF THE DRAWINGS
The teachings of the present invention can be readily understood by
considering the following detailed description in conjunction with the
accompanying drawings, in which:
FIG. 1 depicts an exemplary wireless communication system including
a management system for managing a wireless communication network;
FIG. 2 depicts an exemplary management system suitable for use as
the management system of FIG. 1;
FIG. 3 depicts a high-level block diagram illustrating a discovery and
correlation process performed by the exemplary management system of
FIG. 2 ;
FIG. 4 depicts an exemplary Mobile Service supported by the LTE
network of FIG. 1;
FIG. 5 depicts one embodiment of a method for performing an analysis
function; and
FIG. 6 depicts an exemplary EPS-related path of the LTE network of
FIG. 1.
To facilitate understanding, identical reference numerals have been
used, where possible, to designate identical elements that are common to the
Figures.
DETAILED DESCRIPTION
A management capability is provided for managing a Fourth
Generation (4G) Long Term Evolution (LTE) wireless network. The
management capability may include one or more of an analyzer tool, an audit
tool, a trace tool, an enforcement tool, and the like, as well as combinations
thereof. Although primarily depicted and described herein within the context
of providing management functions within a 4G LTE wireless network, it will
be appreciated that the management functions depicted and described herein
may be utilized within other types of wireless networks.
FIG. 1 depicts an exemplary wireless communication system including
a management system for managing a wireless network. Specifically, FIG. 1
depicts an exemplary wireless communication system 100 that includes a
plurality of User Equipments (UEs) or User Devices (UDs) 102, a Long Term
Evolution (LTE) network 110, non-LTE access networks 120, IP networks
130, and a management system (MS) 140. The LTE network 110 supports
communications between the UEs 102 and IP networks 130. The non-LTE
access networks 120 interface with LTE network 110 for enabling UEs
associated with non-LTE access networks 120 to utilize the LTE network 110
to access IP networks 130. The MS 140 is configured for supporting various
management functions for LTE network 110 .
The UEs 102 are wireless user devices capable of accessing a
wireless network, such as LTE network 110. The UEs 102 are capable of
supporting one or more bearer sessions to IP networks 130 via LTE network
110 . The UEs 102 are capable of supporting control signaling in support of
the bearer session(s). The UEs 102 each may have one or more identifiers
associated therewith. For example, a UE 102 may have one or more of an
International Mobile Subscriber Identity (IMSI), an International Mobile
Equipment Identity (IMEI), and like identifiers or identities associated
therewith. For example, each of the UEs 102 may be a phone, PDA,
computer, or any other wireless user device. Multiple UDs are typically active
at all times for each eNodeB.
The LTE network 110 is an exemplary LTE network. The configuration
and operation of LTE networks will be understood by one skilled in the art.
However, for purposes of completeness, a description of general features of
LTE networks is provided herein within the context of exemplary wireless
communication system 100.
The LTE network 110 includes two eNodeBs 111 and 1112
(collectively, eNodeBs 111) , two Serving Gateways (SGWs) 112 and 1122
(collectively, SGWs 112), a Packet Data Network (PDN) Gateway (PGW) 113,
two Mobility Management Entities (MMEs) 114i and 1142 (collectively, MMEs
114), and a Policy and Charging Rules Function (PCRF) 115. The eNodeBs
111 provide a radio access interface for UEs 102. The SGWs 112, PGW 113 ,
MMEs 114 , and PCRF 115 , as well as other components which have been
omitted for purposes of clarity, cooperate to provide an Evolved Packet Core
(EPC) network supporting end-to-end service delivery using IP.
The eNodeBs 111 support communications for UEs 102. As depicted in
FIG. 1, each eNodeB 111 supports a respective plurality of UEs 102. The
communication between the eNodeBs 111 and the UEs 102 is supported
using LTE-Uu interfaces associated with each of the UEs 102. The eNodeBs
111 may support any functions suitable for being supported by an eNodeB,
such as providing an LTE air interface for the UEs 102, performing radio
resource management, facilitating communications between UEs 102 and
SGWs 112, maintaining mappings between the LTE-Uu interfaces and S 1-u
interfaces supported between the eNodeBs 111 and the SGWs 112, and the
like, as well as combinations thereof.
The SGWs 112 support communications for eNodeBs 111. As depicted
in FIG. 1, SGW 112 supports communications for eNodeB 111 and SGW
112 supports communications for eNodeB 111 . The communication
between the SGWs 112 and the eNodeBs 111 is supported using respective
S 1-u interfaces. The S1-u interfaces support per-bearer user plane tunneling
and inter-eNodeB path switching during handover. The S 1-u interfaces may
use any suitable protocol, e.g., the GPRS Tunneling Protocol - User Place
(GTP-U). The SGWs 112 may support any functions suitable for being
supported by an SGW, such as routing and forwarding user data packets
(e.g., facilitating communications between eNodeBs 111 and PGW 113 ,
maintaining mappings between the S 1-u interfaces and S5/S8 interfaces
supported between the SGWs 112 and PGWs 113 , and the like), functioning
as a mobility anchor for UEs during inter-eNodeB handovers, functioning as a
mobility anchor between LTE and other 3GPP technologies, and the like, as
well as combinations thereof.
The PGW 113 supports communications for the SGWs 112 . The
communication between PGW 113 and SGWs 112 is supported using
respective S5/S8 interfaces. The S5 interfaces provide functions such as user
plane tunneling and tunnel management for communications between PGW
113 and SGWs 112, SGW relocation due to UE mobility, and the like. The S8
interfaces, which are Public Land Mobile Network (PLMN) variants of the S5
interfaces, provide inter-PLMN interfaces providing user and control plane
connectivity between the SGW in the Visitor PLMN (VPLMN) and the PGW in
the Home PLMN (HPLMN). The S5/S8 interfaces may utilize any suitable
protocol (e.g., the GPRS Tunneling Protocol (GTP), Mobile Proxy IP (MPIP),
and the like, as well as combinations thereof). The PGW 113 facilitates
communications between LTE network 110 and IP networks 130 via an SGi
interface. The PGW 113 may support any functions suitable for being
supported by an PGW, such as providing packet filtering, providing policy
enforcement, functioning as a mobility anchor between 3GPP and non-3GPP
technologies, and the like, as well as combinations thereof.
The MMEs 114 provide mobility management functions in support of
mobility of UEs 102. The MMEs 114 support the eNodeBs 111. The MME
114i supports eNodeB 111 and the MME 1142 supports eNodeB 1112. The
communication between MMEs 114 and eNodeBs 111 is supported using
respective S 1-MME interfaces, which provide control plane protocols for
communication between the MMEs 114 and the eNodeBs 111. The S1-MME
interfaces may use any suitable protocol or combination of protocol. For
example, the S1-MME interfaces may use the Radio Access Network
Application Part (eRANAP) protocol while using the Stream Control
Transmission Protocol (SCTP) for transport. The MMEs 114 support the
SGW 112. The MME 114i supports SGW 112i and the MME 1142 supports
SGW 1122. The communication between MMEs 114 and SGWs 112 is
supported using respective S 11 interfaces. The MMEs 114Ϊ and 1142
communicate using an S 10 interface. The MMEs 114 may support any
functions suitable for being supported by a MME, such selecting SGWs for
UEs at time of initial attachment by the UEs and at time of intra-LTE
handovers, providing idle-mode UE tracking and paging procedures, bearer
activation/deactivation processes, providing support for Non-Access Stratum
(NAS) signaling (e.g., terminating NAS signaling, ciphering/integrity protection
for NAS signaling, and the like), lawful interception of signaling, and the like,
as well as combinations thereof. The MMEs 114 also may communicate with
a Home Subscriber Server (HSS) using an S6a interface for authenticating
users (the HSS and the associated S6a interface are omitted for purposes of
clarity).
The PCRF 115 provides dynamic management capabilities by which
the service provider may manage rules related to services provided via LTE
network 110 and rules related to charging for services provided via LTE
network 110 . For example, rules related to services provided via LTE network
110 may include rules for bearer control (e.g., controlling acceptance,
rejection, and termination of bearers, controlling QoS for bearers, and the
like), service flow control (e.g., controlling acceptance, rejection, and
termination of service flows, controlling QoS for service flows, and the like),
and the like, as well as combinations thereof. For example, rules related to
charging for services provided via LTE network 110 may include rules related
to online charging (e.g., time-based charging, volume-based charging, eventbased
charging, and the like, which may depend on factors such as the type
of service for which charging is being provided), offline charging (e.g., such as
for checking subscriber balances before services are provided and other
associated functions), and the like, as well as combinations thereof. The
PCRF 115 communicates with PGW 113 using a S7 interface. The S7
interface supports transfer of rules from PCRF 115 to a Policy and Charging
Enforcement Function (PCEF) supported by PGW 113, which provides
enforcement of the policy and charging rules specified on PCRF 115 .
As depicted in FIG. 1, elements of LTE network 110 communicate via
interfaces between the elements. The interfaces described with respect to
LTE network 110 also may be referred to as sessions. For example, the
communication between eNodeBs and SGWs is provided via S 1-u sessions,
communication between SGWs and PGWs is provided via S5/S8 sessions,
and so forth, as depicted in FIG. 1 and described herein. The sessions of
LTE network 110 may be referred to more generally as S* sessions. It will be
appreciated that each session S* that is depicted in FIG. 1 represents a
communication path between the respective network elements connected by
the session and, thus, that any suitable underlying communication capabilities
may be used to support the session S* between the network elements. For
example, a session S* may be supported using anything from direct hardwired
connections to full network connectivity (e.g., where the session S* is
transported via one or more networks utilizing nodes, links, protocols, and any
other communications capabilities for supporting the communication path) and
anything in between, or any other suitable communications capabilities.
For example, an S 1-u session between an eNodeB 111 and an SGW
112 may be supported using an Internet Protocol (IP) / Multiprotocol Label
Switching (MPLS) transport capability including mobile backhaul elements
associated with the eNodeB 111 (e.g., using service aware routers (SARs),
service access switches (SAS), and the like) and mobile backhaul elements
associated with the SGW 112 (e.g., multi-service edge routers and/or other
similar elements), as well as an IP/MPLS aggregation network facilitating
communications between the mobile backhaul elements associated with the
eNodeB 111 and the mobile backhaul elements associated with the SGW
112). Similarly, an S 1-u session between an eNodeB 111 and an SGW 112
may be supported using an IP routing network using a routing protocol (e.g.,
Open Shortest Path First (OSPF), Intermediate System to Intermediate
System (ISIS) and the like). The types of underlying communications
capabilities which may be utilized to support each of the different types of
sessions of LTE network 110 will be understood by one skilled in the art.
The LTE network 110 supports access to IP networks 130 from non-
LTE networks 120.
The non-LTE networks 120 with which the LTE network 110 may
interface include 3GPP access networks 121 . The 3GPP access networks
121 may include any 3GPP access networks suitable for interfacing with LTE
network 110 (e.g., 2.5G networks, 3G networks, 3.5G networks, and the like).
For example, the 3GPP access networks 121 may include Global System for
Mobile (GSM) Enhanced Data Rates for GSM Evolution (EDGE) Radio
Access Networks (GERANs), Universal Mobile Telecommunications System
(UMTS) Terrestrial Radio Access Networks (UTRANs), or any other 3GPP
access networks suitable for interfacing with LTE, and the like, as well as
combinations thereof.
The LTE network 110 interfaces with 3GPP access networks 121 via a
Serving General Packet Radio Service (GPRS) Support Node (SGSN) 122.
The MME 1142 supports control plane functionality for mobility between LTE
network 110 and 3GPP access networks 121 using communication with
SGSN 122 via an S3 interface. For example, the S3 interface enables user
and bearer information exchange for 3GPP network access mobility in idle
and/or active state. The SGW 112 supports user plane functionality for
mobility between LTE network 110 and 3GPP access networks 121 using
communication with SGSN 122 via an S4 interface. For example, the S4
interface provides the user plane with related control and mobility support
between SGSN 122 and SGW 1122.
The non-LTE networks with which the LTE network may interface
include non-3GPP access networks 125. The non-3GPP access networks
125 may include any non-3GPP access networks suitable for interfacing with
LTE network 110. For example, the non-3GPP access networks may include
3GPP2 access networks (e.g., Code Division Multiple Access 2000 (CDMA
2000) networks and other 3GPP2 access networks), Wireless Local Area
Networks (WLANs), and the like. The support for mobility between the LTE
network 110 and the non-3GPP access networks 125 may be provided using
any suitable interface(s), such as one or more of the S2a interface, the S2b
interface, the S2c interface, and the like, as well as combinations thereof.
The S2a interface provides control and mobility support to the user plane for
trusted non-3GPP access to the LTE network. The S2a interface may provide
access for trusted non-3GPP networks using any suitable protocol(s), such as
MPIP, Client Mobile IPv4 Foreign Agent (FA) mode (e.g., for trusted non-
3GPP access that does not support MPIP), and the like, as well as
combinations thereof. The S2b interface provides control and mobility support
to the user plane for non-trusted non-3GPP access to the LTE network. The
S2b interface may be provided an interface between PGW 113 and an
evolved Packet Data Gateway (ePDG) associated with the non-trusted non-
3GPP access network. The S2b interface may use any suitable protocol,
such as MPIP or any other suitable protocols. The S2c interface provides
control and mobility support to the user plane for providing UEs access to
PGW 113 via trusted and/or non-trusted 3GPP access using one or more
protocols based on Client Mobile IP co-located mode.
The LTE network 110 includes an Evolved Packet System/Solution
(EPS). In one embodiment, the EPS includes EPS nodes (e.g., eNodeBs
111, SGWs 112, PGW 113 , MMEs 114 , and PCRF 115) and EPS-related
interconnectivity (e.g., the S* interfaces, the G* interfaces, and the like). The
EPS-related interfaces may be referred to herein as EPS-related paths.
The IP networks 130 include one or more packet data networks via
which UEs 102 may access content, services, and the like. For example, the
IP networks 130 include an IP Core network and, optionally, one or more
other IP networks (e.g., IP Multimedia Subsystem (IMS) networks and the
like). The IP networks 130 support bearer and control functions in support of
services provided to UEs 102 via LTE network 110 . The IP Core network is
capable of providing any functions which may be provided by such a core
network. The IP Core network is a packet data network via which UEs 102
may access content, services, and the like.
The IMS network is capable of providing any functions which may be
provided by an IMS network.
The MS 140 provides management functions for managing the LTE
network 110 . The MS 140 may communicate with LTE network 110 in any
suitable manner. In one embodiment, for example, MS 140 may communicate
with LTE network 110 via a communication path 141 which does not traverse
IP network networks 130. In one embodiment, for example, MS 140 may
communicate with LTE network 110 via a communication path 142 which via
IP network networks 130. The communication paths 141 and 142 may be
implemented using any suitable communications capabilities. An exemplary
management system suitable for use as MS 140 of FIG. 1 is depicted and
described with respect to FIG. 2 .
As depicted and described herein, the communication system 100 is
merely exemplary. It will be appreciated that, although depicted and described
herein with respect to specific numbers and arrangements of eNodeBs 111,
SGWs 112, PGW 113 , MMEs 114, and PCRF 115 , an LTE wireless network
may be implemented using different numbers and/or arrangements of
eNodeBs 111, SGWs 112, PGW 113, MMEs 114, and PCRF 115 . For
example, LTE networks are typically implemented hierarchically, such as
where the LTE network includes one or more PGWs, each of the PGWs
supports respective pluralities of SGWs, and each of the SGWs supports
respective pluralities of eNodeBs. It will be further appreciated that, although
depicted and described herein with respect to an LTE wireless network that
supports specific types of interfaces (namely, the S* interfaces, as well as
other non-S interfaces), many other types of interfaces may be supported
between elements of an LTE wireless network and/or between components of
an LTE wireless network and components of non-LTE wireless networks. As
such, management functions depicted and described herein are not limited to
use in any particular configuration of an LTE wireless network.
FIG. 2 depicts an exemplary management system suitable for use as
the management system of FIG. 1. As depicted in FIG. 2 , MS 140 includes a
processor 2 10 , a memory 220, a network interface 230 N, and a user interface
230|. The processor 2 10 is coupled to each of the memory 220, the network
interface 230N, and the user interface 230|.
The processor 2 10 is adapted to cooperate with the memory 220, the
network interface 230N, the user interface 230|, and the support circuits 240 to
provide various management functions for LTE network 110 .
The memory 220, generally speaking, stores data and tools that are
adapted for use in providing various management functions for LTE network
110 . The memory includes a Discovery Engine (DE) 221 , a Discovery
Database (DD) 222, a Correlation Engine (CE) 223, a Paths Database (PD)
224, an Analyzer Tool (ANT) 225, an Audit Tool (AUT) 226, a Trace Tool (TT)
227, and a Fairness Management Tool (FMT) 228.
In one embodiment, the DE 221 , CE 223, ANT 225, AUT 226, TT 227,
and FMT 228 are implemented using software instructions which may be
executed by processor (e.g., processor 2 10) for performing the various
management functions depicted and described herein.
The DD 222 and PD 224 each store data which may be generated by
and used by various ones and/or combinations of the engines and tools of
memory 220. The DD 222 and PD 224 may be combined into a single
database or may be implemented as respective databases. Either of the
combined or respective databases may be implemented as single databases
or multiple databases in any of the arrangements known to those skilled in the
art.
Although depicted and described with respect to an embodiment in
which each of the engines, databases, and tools is stored within memory 120,
it will be appreciated by those skilled in the art that the engines, databases,
and/or tools may be stored in one or more other storage devices internal to
MS 140 and/or external to MS 140. The engines, databases, and/or tools
may be distributed across any suitable numbers and/or types of storage
devices internal and/or external to MS 140. The memory 220, including each
of the engines, databases, and tools of memory 220, is described in additional
detail herein below.
The network interface 230N is adapted to facilitate communications with
LTE network 110 . For example, network interface 230N is adapted to receive
information from LTE network 110 (e.g., discovery information adapted for use
in determining the topology of LTE network, results of test initiated by MS 140
to LTE network 110 , and the like, as well as any other information which may
be received by MS 140 from LTE network 110 in support of the management
functions performed by MS 140). Similarly, for example, network interface
230N is adapted to transmit information to LTE network 110 (e.g., discovery
requests for discovering information adapted for use by MS 140 in
determining the topology of LTE network, audits request for auditing portions
of LTE network 110 , and the like, as well as any other information which may
be transmitted by MS 140 to LTE network 110 in support of the management
functions performed by MS 140).
The user interface 230| is adapted to facilitate communications with
one or more user workstations (illustratively, user workstation 250), for
enabling one or more users to perform management functions for LTE
network 110 . The communications include communications to user
workstation 250 (e.g., for presenting imagery generated by MS 140) and
communications from user workstation 250 (e.g., for receiving user
interactions with information presented via user workstation 250). Although
primarily depicted and described as a direct connection between MS 140 and
user workstation 250, it will be appreciated that the connection between MS
140 and user workstation 250 may be provided using any suitable underlying
communication capabilities, such that user workstation 250 may be located
proximate to MS 140 (e.g., such as where both MS 140 and user workstation
250 are located within a Network Operations Center (NOC)) or remote from
MS 140 (e.g., such as where communications between MS 140 and user
workstation 250 may be transported over long distances).
Although primarily depicted and described herein with respect to one
user workstation, it will be appreciated that MS 140 may communicate with
any suitable number of user workstations, such that any number of users may
perform management functions for LTE network 110 (e.g., such as where a
team of technicians at a NOC access MS 140 via respective user
workstations for performing various management functions for LTE network
110). Although primarily depicted and described with respect to user
workstations, it will be appreciated that user interface 230| may be adapted to
support communications with any other devices suitable for use in managing
LTE network 110 via MS 140 (e.g., for displaying imagery generated by MS
140 on one or more common NOC display screens, for enabling remote
Virtual Private Network (VPN) access to MS 140 by users via remote
computers, and the like, as well as various combinations thereof). The use of
user workstations to perform management functions via interaction with a
management system will be understood by one skilled in the art.
As described herein, memory 220 includes the DE 221 , DD 222, CE
223, PD 224, ANT 225, AUT 226, TT 227, and FMT 228, which cooperate to
provide the various management functions depicted and described herein.
Although primarily depicted and described herein with respect to specific
functions being performed by and/or using specific ones of the engines,
databases, and/or tools of memory 220, it will be appreciated that any of the
management functions depicted and described herein may be performed by
and/or using any one or more of the engines, databases, and/or tools of
memory 220.
The engines and tools may be activated in any suitable manner. In one
embodiment, for example, the engines and tools may be activated in
response to manual requests initiated by users via user workstations, in
response to automated requests initiated by MS 140, and the like, as well as
various combinations thereof.
For example, where an engine or tool is activated automatically, the
engine or tool may be activated in response to scheduled requests, in
response to requests initiated by MS 140 based on processing performed at
MS 140 (e.g., such as where results generated by CE 223 indicate that ANT
225 should be invoked, such as where results of an audit performed by ANT
225 indicate that the TT 227 should be invoked, such as where results of a
mobile session path trace performed by TT indicate that FMT 228 should be
invoked, and the like, as well as combinations thereof). A description of the
engines, databases, and tools of MS 140 follows.
In one embodiment, where an automatically triggered engine or tool
begins to consume computing or other resources above a threshold level,
subsequent automatic triggering of the engine or tool is constrained. In this
embodiment, an alarm or status indicator is provided to the network manager
indicative of the constrained automatic triggering condition such that the
network manager or operating personnel may assume direct or manual
control of the engine or tool.
EPS-Path to Infrastructure Correlation.
As previously noted, various embodiments of an LTE network 110
include an Evolved Packet System/Solution (EPS) infrastructure having EPS
nodes (e.g., eNodeBs 111, SGWs 112, PGW 113 , MMEs 114, and PCRF
115) and EPS-related interconnectivity (e.g., S* interfaces, the G* interfaces,
and the like). Within the context of this present disclosure, the EPS-related
interfaces are referred to herein as EPS-related paths or simply paths.
The infrastructure is architected to provide the appropriate and
necessary EPS nodes for supporting the wireless services offered by the
network service provider. The network service provider manages the network
to provide its service offerings to its wireless/mobile users in a manner
consistent with the consumer expectations. For example, wireless/mobile
users (e.g., users of standard telephones, smart phones, computers and the
like purchasing various voice, data or other service offerings) expect near
perfect telephone/voice service, very near perfect data services, glitch-free
streaming media and the like. Third party service providers purchasing
service bundles for their own users expect the same, as well as management
level interfaces and other mechanisms to provide interoperability between the
various networks. Customer expectations may comprise an assumed or
expected level of service, a level of service defined in a service level
agreement (SLA) and the like.
Various embodiments are directed to network management systems
and tools wherein each EPS-related interconnection is correlated to the
specific infrastructure necessary to support that functionality. That is, for each
EPS-related path, an association is made to the specific infrastructure
necessary to support that path, including the network elements, sub-elements,
links and so on which, if they fail or degrade, will result in failure or
degradation of the associated EPS-related path.
By understanding which traffic flows or paths include an element, sub
element or link as a necessary support element, the network management
system can then know which traffic flows or paths are impacted by the
degradation/failure of a specific element, sub element or link. This is
especially useful in the context of an analysis tool, as will be discussed in
more detail elsewhere.
Similarly, by understanding which traffic flow or path has failed or
degraded, the network management system can then identify which elements,
sub elements or links are necessary to support the traffic flow or path. In this
manner, the network manager reduces the complexity of identifying the
element(s), sub-element(s) and/or link(s) that failed/degraded element or sub
element associated with the traffic flow or path that failed or degraded. This is
especially useful in the context of a trace tool, as well be discussed in more
detail elsewhere.
Within the context of correlation, the management system may create a
service representation for each connection between a network element or
sub-element.
For example, if a specific output port of a first network element
transmits data to a destination address associated with a second network
element, and a specific input port of the second network element receives
data from a source address associated with the first network element, the
service aware manager creates a service representation indicating that the
specific output port of the first network element and specific input port of the
second network element are connected. If either of the ports associated with
the service representation fails or degrades, then the service supported by the
packet flow between the specific ports will also fail or degrade. However,
either of the network elements having ports associated with the service
representation would normally not detect a failure of the other network
element. In the event of a failure of the transmitting port of the first network
element, the second network element would not necessarily realize that a
failure has occurred. Similarly, in the event of a failure of the receiving port of
the second network element, the first network element would not necessarily
realize that a failure has occurred.
In various embodiments, a connection is provided between ports at
either or both of the physical level (e.g., a cable or other physical level link) or
the service level (e.g., a generalized cloud or other service level link).
In one physical level connection embodiment, if a port (or other
subelement) on a first network element (NE) fails, then a corresponding or
connected port (or other subelement) on a second NE will show a link down
status (LLDP). In this manner, the second NE is aware of the failure of the
first NE. In other physical level connection embodiment, such awareness is
provided within the context of neighboring network elements, such as routers
or switches and/or their various subelements.
In one service level embodiment, a port (or other subelement) on a first
NE may be connected directly to a port (or other subelement) on a second
NE, or through one or more ports (or other subelements) of one or more NEs
(i.e., multiple hops between the first and second NEs). In this embodiment, if
the port (or other subelement) on the first or any intermediate NE fails or
degrades, the management system may not be aware that the
failure/degradation exists due to the operational status of the last NE in the
sequence of NEs. However, due to the management techniques and tool
discussed herein, the network manager is made aware of the initial or
intermediate failure/degradation. Various causes of this behavior include
congestion, local/regional rerouting and the like. In brief, status indicators are
green (indicative of appropriate operation), but the performance of this portion
of the network is constrained or degraded. This constrained or degraded
network operation is correlated and illustrated by the various embodiments
discussed herein.
Discovery Tool/Function
The discovery engine (DE) 221 is generally adapted for providing
network discovery functions for discovering information about LTE network
110 . Generally speaking, the DE 221 performs a discovery process in which
configuration information, status/operating information and connection
information regarding the elements and sub-elements forming the network is
gathered, retrieved, inferred and/or generated as will be discussed in more
detail below.
The discovery process may be dynamic in that the underlying
elements, sub-elements and links within the LTE network may change over
time due to local network adaptations, rerouting, failures, degradations,
scheduled maintenance and the like. Thus, the DE 221 may be invoked after
a network change is detected or caused by any of the ANT 225, AUT 226, TT
227, and FMT 228.
At a first discovery level, the network management system (NMS) uses
any legacy database information to discover the various elements (and the
corresponding sub-elements) forming the network to be managed. That is,
some of this discovery comprises the use of existing database information
which provides a general blueprint of the network to be managed. Information
in such a database includes information associated with the major functional
elements forming a network, the major pipes or conduits established within
the network and so on. While such information may be extremely detailed,
the information does not reflect path-level network operation.
At a second discovery level, the network management system requests
configuration information, status/operating information and connection
information from each of the network elements within the managed network.
The requested information includes information useful in determining the
specific switches, ports, buffers, protocols and the like within the network
elements that support the various traffic flows.
The network management system may also utilize the existing
database information to infer possible connections between network elements
and sub-elements and connections within the network being managed. For
example, the existing database information may be constructed as depicting a
sequence of connected network elements that may support traffic flows
between them. However, the existing database information likely does not
include information identifying the specific switches, ports, buffers, protocols,
address information of received/transmitted packets and the like within the
network elements that support the various traffic flows.
Configuration information comprises information identifying a network
element, the function and/or configuration of the network element, the function
and/or configuration of the sub-elements forming a network element and so
on. Configuration information illustratively includes, but is not limited to,
information identifying the type of network element, protocols supported by
the network element, services supported by the network element and so on.
Configuration information illustratively includes information attending to the
various sub-elements within the network element, such as the input ports,
switches, buffers, and output ports and so on associated with the subelements
forming a network element.
Status/operating information comprises status/operating information
associated with the operating state of the network element and/or the subelements
forming a network element. Status/operating information
illustratively includes, but is not limited to, information providing operating
status/alarm indicators, including information pertaining to metrics such as
packet count, utilization level, component pass/fail indication, bit error rate
(BER) and the like.
Connection information comprises information useful in ascertaining or
inferring the connections between network elements and/or sub-elements,
such as the source of data received from the network element or its subelements,
the destination of data transmitted by the network element or its
sub-elements and so on. That is, connection information is information
provided by a network element from the subjective perspective of the network
element. The network element does not necessarily have information
specifically identifying the network elements from which it receives packets or
the network element toward which it transmits packets.
Connection information illustratively includes, but is not limited to,
source address information associated with received packets, destination
address information associated with transmitted packets, protocol information
associated with packet flows, service information associated with packet
flows, deep packet inspection results data and the like.
At a third discovery level, the network management system uses the
discovered information to form a detailed framework representing each of the
elements, sub-elements and links forming the infrastructure of the network, as
well as their respective and various interconnections.
Generally speaking, the DE 221 may discover any suitable information
associated with LTE network 110 , which may be referred to collectively herein
as discovery information, and further divided into configuration information,
status/operating information and connection information.
In one embodiment, for example, DE 221 discovers components of the
LTE network 110 and information associated with components of the LTE
network 110. The components of LTE network 110 that are discovered by DE
221 may include any components, such as network elements (EPC network
elements, non-EPC network elements, and the like), sub-elements of network
elements (e.g., chassis, traffic cards, control cards, interfaces, ports,
processors, memory, and the like), communication links connecting network
elements, interfaces/sessions that support communications between network
elements (e.g., LTE-Uu sessions, S* sessions, and the like), reference points,
functions, services, and the like, as well as combinations thereof.
For example, DE 221 may discover the network elements of LTE
network 110 (e.g., EPC network elements such as the eNodeBs 111, SGWs
112 , PGW 113 , MMEs 114 , PCRF 115 , and the like; non-EPC network
elements that facilitate communication via sessions between the EPC network
elements; and the like, as well as combinations thereof).
For example, DE 221 may discover network element configuration
information associated with network elements of LTE network 110 (e.g.,
chassis configurations, line cards, ports on the line cards, processors,
memory, and the like, which may depend on the types of network elements for
which discovery is performed).
For example, DE 221 may discover interface/session information (e.g.,
information associated with LTE-Uu sessions, information associated with S*
sessions, and the like, as well as combinations thereof). For example, DE
221 may discover reference points of LTE network 110 (e.g., the LTE-Uu, S 1-
u , S 1-MME, X2, and other reference points associated with eNodeBs; the S 1-
u , S5/S8, S 11, S4, and other reference points associated with SGWs; the
S5/S8, SGi, SGx, S7, S2a, S2b, S2c, and other reference points associated
with PGWs; the S 1-MME, S 11, S 10 , and other reference points associated
with MMEs, the S7 and other reference points associated with PCRFs; and
the like).
For example, DE 221 may discover functions, services, and the like, as
well as combinations thereof. For example, DE 221 may discover information
related to connectivity between network elements of LTE 110 , which may
include physical connectivity information and logical connectivity information
(e.g., identification of communication links deployed within LTE network 110 ,
identification of wavelengths being transported over particular fibers within
LTE network 110, and the like, as well as combinations thereof).
The DE 221 may discover any other information that is associated with
LTE network 110 and which is or may be suitable for use in providing the
various management functions depicted and described herein (e.g., for use by
CE 223 in determining paths of LTE network 110 , for use by ANT 225 in
performing analysis for LTE network 110 , for use by AUT 226 in performing
audits within LTE network 110 , for use by TT 227 in performing mobile
session path traces for mobile sessions within LTE network 110, for use by
FMT 228 for providing enforcement functions within LTE network 110 , and the
like, as well as combinations thereof).
The DE 221 may discover the information associated with LTE network
110 in any suitable manner (e.g., from any suitable sources, at any suitable
times, using any suitable protocols, in any suitable formats, and the like, as
well as combinations thereof).
In one embodiment, for example, DE 221 may receive discovery
information associated with LTE network 110 from one or more management
systems associated with LTE network 110 (e.g., from other management
systems, such as network inventory systems, network provisioning systems,
and the like), from one or more element management systems (EMSs)
managing respective subsets of the network elements of LTE network 110 ,
from the network elements of LTE network 110 , and the like, as well as
combinations thereof.
In one embodiment, for example, the DE 221 may receive discovery
information upon initial boot-up of elements of LTE network 110 , via periodic
updates initiated by elements of LTE network 110 , in response to periodic
updates requested by DE 221 , in response to on-demand requests initiated by
DE 221 , and the like, as well as combinations thereof. The periodic requests
may be configured to be performed using at any suitable intervals.
On-demand requests to the DE 221 may be in initiated in response to
any suitable trigger conditions (e.g., in response to manually requests initiated
by a user via user workstation 2 10 , in response to requests initiated by CE
223 for purposes of obtaining additional discovery information for use in
performing correlation functions, in response to requests initiated by ANT 225
for purposes of obtaining additional discovery information for use in
performing analysis functions, in response to requests initiated by AUT 226
for purposes of obtaining additional discovery information for use in
performing audit functions, in response to requests initiated by AT 227 for
purposes of obtaining additional discovery information for use in performing
trace functions, in response to requests initiated by FMT 228 for purposes of
obtaining additional discovery information for use in performing enforcement
functions, and the like, as well as combinations thereof)
The DE 221 may receive the discovery information using any suitable
management and/or communications protocols. In one embodiment, for
example, the DE 221 may receive discovery information via one or more of
Simple Network Management Protocol (SNMP) traps, Network Configuration
Protocol (NETCONF) messages, Transaction Language 1 (TL1 ) messages,
and the like, as well as various combinations thereof.
The discovered information is stored in one or more databases to
facilitate rapid retrieval by network operations personnel and/or other users,
such as the Discovery Database (DD) 222. The DD 222 may store the
discovery information in any suitable format, as will be understood by one
skilled it the art. The DD 222 provides a repository of discovery information
for use by CE 223 and, optionally, for use by one or more of ANT 225, AUT
226, TT 227, and FMT 228 for providing their respective management
functions.
Correlation Engine Tool/Function
The CE 223 provides correlation of information used to support the
management functions depicted and described herein. The CE 223 utilizes
configuration information, status/operations information and/or connections
information, illustratively provided by the DE 221 and stored within the DD
222, to correlate discovered network element, sub-element and link functions
to specific customer traffic flows and/or paths supporting customer services.
That is, using the framework representing each of the elements, sub-elements
and links within the network and their various interconnections, the CE 223
correlates each customer service, traffic flow and/or EPS-path to the specific
elements, sub-elements and links necessary to support the customer service,
traffic flow and/or path.
The correlation process may be dynamic in that, for any given path, the
underlying elements, sub-elements and links supporting that path may change
over time due to local network adaptations, rerouting, failures, degradations,
scheduled maintenance and the like. Thus, CE 223 may be invoked after a
network change is detected or caused by any of the ANT 225, AUT 226, TT
227, and FMT 228.
The CE operates to maintain a current representation of the necessary
supporting infrastructure associated with each customer service, traffic flow
and/or path. By providing this representation, efforts responsive to customer
service failure or degradation can be focused on the specific element, subelement
and link functions supporting the impacted customer service (e.g., by
using TT 227). Similarly, efforts responsive to element, sub-element and link
function failure or degradation can be focused on the specific customers
and/or services supported by the impacted element, sub-element and link
function.
Typically, only a small subset of the sub-elements within a particular
element is necessary to support a particular path. Thus, a failure associated
with other sub-elements within an element does not impact that particular
path. By correlating to each path only those elements necessary to support
the path, the processing/storage burdens associated with managing individual
paths are reduced by avoiding processing/storage requirements associated
with nonessential (from the perspective of a particular path) elements.
In one embodiment, CE 223 may process discovery information stored
in DD 222 for purposes of determining the underlying transport elements
supporting the paths of LTE network 110 , which is then stored in PD 224. In
one embodiment, the path correlated transport element information
determined by CE 223 and stored in PD 224 include EPS-related paths of
LTE network 110. In general, an EPS-related path is a path that is a transport
mechanism that represents a peering relationship between two EPS reference
points, where an EPS reference point is a termination point for any node of
LTE network 110 that implements one or more of the protocols present in the
4G specification (e.g., using GTP, PMIP, or any other suitable protocols, and
the like, as well as combinations thereof). The path correlated transport
element information may comprise network elements, communications links,
subnets, protocols, services, applications, layers and any portions thereof.
These transport elements may be managed by the network management
system or portions thereof. The network management system may simply be
aware of these transport elements.
As depicted and described herein, EPS reference points may include:
for an eNodeB (S1-u, S 1-MME, X2, and the like); for an SGW 112 (S1 -u,
S5/S8, S 11, Gxs, and the like); for a PGW (S5/S8, SGi, SGx, S7, S2a, S2b,
S2c, and the like); for an MME (S1 -MME, S 11, S 10 , and the like); and for a
PCRF (S7). Thus, EPS-related paths correspond generally to the various S*
sessions between the eNodeBs and EPC nodes (e.g., a path between an
eNodeB 111 and an SGW 112 in the case of S 1-u reference points, a path
between an SGW 112 and PGW 113 in the case of S5/S8 reference points, a
path between an eNodeB 111 and an MME 114 in the case of S 1-MME
reference points, and the like).
In one embodiment, the path correlated transport element information
determined by CE 223 and stored in PD 224 include other types of paths
(e.g., paths other than EPS-related paths). For example, the other types of
paths may includes one or more of: ( 1) paths that form sub-portions of EPSrelated
paths (e.g., where an EPS-related path is supported using underlying
communications technology, the path that forms a sub-portion of the EPSrelated
path may be a path associated with the underlying communications
technology, (2) paths that include multiple EPS-related paths (e.g., paths from
eNodeBs to PGWs that traverse both S 1-u and S5/S8 sessions, paths from
UEs to SGWs that traverse both LTE-Uu sessions and S1-u sessions, and the
like), and (3) end-to-end mobile session paths (e.g., paths between UEs and
IP networks). The path correlated transport element information determined
by CE 223 and stored in PD 224 may include other information correlated with
various types of paths.
The path correlated transport element information determined by the
CE 223 and stored in the PD 224 may be determined using any suitable
processing.
The CE 223 is adapted for making direct correlations between
discovered components of LTE network 110 . For example, CE 223 may
determine from the discovery information that a particular port on an eNodeB
is connected to a particular port on a service router used to provide backhaul
between the eNodeB and its SGW. For example, CE 223 may determine
from the discovery information that a particular S 1-u reference point on an
eNodeB 111 is coupled to a particular S 1-u reference point on an SGW 112.
For example, CE 223 may determine from the discovery information that, for a
given SGW 112, a particular S1-u interface on the eNodeB facing side of the
SGW 112 maps to a particular S5/S8 reference point on the PGW facing side
of the SGW 112. It will be appreciated that the foregoing examples are just a
few of the many possible correlations which may be made by CE 223. The CE
223 is adapted for making any correlations between discovered components
of LTE network 110 that enable CE 223 to determine a comprehensive view
of the entire LTE network at all layers (e.g., from the physical layer all the way
through the application layer and everything in between).
The CE 223 is adapted for making inferences regarding associations
between discovered components of LTE network 110 . For example, CE 223
may have information indicating that certain data is being transmitted from a
certain port on an eNodeB via a S 1-u interface of the eNodeB and may have
information indicating that certain data is being received at a certain port on
an SGW via an S1-u interface of the SGW, and may use this information
about the data in order to infer that the port of the eNodeB and the port of the
SGW are logically connected for communicating via the S 1-u interface. For
example, CE 223 may have information indicating that the interface on an
eNodeB is directly connected to the SGW through a physical Link, through a
routed network, or through a VPN service (L2, L3).
In one embodiment, the network manager within which the CE 223 is
operative includes substantially all of the information related to the peering of
different EPS Paths (including S1-u). From that peering information, the CE
223 may identify nodes on each end of a path and then identify or examine
the corresponding neighbor nodes. From the neighbor node information, the
CE 223 may then identify or examine a next group of neighbor nodes and so
on.
This process of identifying or examining in sequence each subsequent
group of neighbor nodes advantageously uses the incrementally gained
neighborhood node information to reduce (or filter) candidate neighbors to
form thereby a smaller list. This process, especially when used in conjunction
with a topology Discovery Profile (template) selected by the operator, reduces
the complexity and processing resource allocation associated with the
correlation process.
A topology Discovery Profile or template is an association of a path
with a "hint" or other guidance indicative of a type of path, Mobile Service,
segments forming the path or Mobile Service, types of nodes at the endpoint
of the segments and so on. For example, a particular network operator may
typically architect paths according to one of two or three standard techniques.
In this case, the operator may provide a hint about the architecture pertaining
to a path of interest.
A topology Discovery Profile or template is especially useful within the
context of a trying to manage a cloud or unmanageable portion of a network,
such as a portion of a network leased from a third party network provider. For
example, to fill out service gaps within a network, a network operator may
lease network services from a third party. Unfortunately, while the third party
is obligated to provide the leased services according to a service-level
agreement, the third party typically does not provide any ability for the network
operator leasing the services to manage infrastructure within the third party
network supporting the leased network services.
In one embodiment, the third party network operator providing the
leased services provides hints or a profile/template indicative of the likely
topology or infrastructure used to support the leased services. That is, the
network operator provides services according to one or more of a finite
number of topology options or infrastructure options. The network operator
may provide this information to the lessee such that the service aware
manager of the lessee may more clearly understand the particular
infrastructure elements supporting the paths through the leased portion of its
network.
For example, a network operator may indicate or "hint" that a particular
S 1-u corresponds to a particular Discovery Profile or template number, where
each number represents a particular topology or infrastructure. For example,
a first hint or template may provide that connections between an eNodeB and
a SGW are provided by a specific number of segments or links, where each
segment or link corresponds to a respective segment or link type, and where
each of the segments or links interconnects eNodeBs, switches, routers and
other network elements in a particular manner. For example, an operator hint
or profile may indicate that a first segment is a pure routing segment, a
second segment is a physical Link (e.g., LLDP will automatically provide a
peer), a third segment is an E-Pipe (P2P L2VPN) and so on. Other hints or
templates may provide different topologies, connections arrangements and
the like.
The correlation engine begins processing a path upon discovering that
path from a managed network element. The correlation engine calculates,
infers and/or otherwise discovers the various infrastructure elements, subelements
and links supporting that path upon discovery of the path.
In one embodiment, an initial S1-u reference point in the SGW is
discovered. When any reference points or S-peers is discovered, a
corresponding S- path is then formed.
In various embodiments, a service aware manager provides discovery
and/or correlation of the entire network at once, by section or region, or by
individual nodes or network elements. In this manner, EPS peers can be
discovered (or resynchronized) throughout the operational life of the service
aware manager. For example, EPS peers may be created in accordance with
a discovery or with an event (e.g., an SNMP Trap or other event) indicating
that a new EPS Peer has been created on a NE. This may happen,
illustratively, when an operator is installing a new eNodeB in the network and
the newly installed eNodeB becomes the peer of an existing (and already
managed) SGW.
It will be appreciated that the foregoing examples are just a few of the
many possible inferences which may be made by CE 223. The CE 223 is
adapted for making any inferences related to correlation of discovered
components of LTE network 110 that enable CE 223 to determine a
comprehensive view of the entire LTE network at all layers (e.g., from the
physical layer all the way through the application layer and everything in
between).
The paths determined by the CE 223 may have any suitable path
information associated therewith. In one embodiment, for example, path
information associated with an EPS-related path may include any information
indicative of the underlying communications capabilities supporting the EPSrelated
path. For example, the path information for an EPS-related path may
include information identifying S* reference points forming the endpoints of
the EPS-related path, identifying network elements supporting the path (e.g.,
routers, switches, and the like), identifying ports on the network elements that
support the path, identifying IP interfaces supporting the path, specifying
configurations of the IP interfaces supporting the path, specifying the
configurations of the ports of network elements that support the path (e.g.,
administrative configurations, operational configurations, and the like), and the
like, as well as combinations thereof.
For example, the path information for an EPS-related path may include
other information that is associated with the portions of the underlying
communication network supporting the EPS-related path, e.g., identification of
communication links between network elements, identification of logical paths
on the communication links (e.g., such as specific MPLS paths supporting the
EPS-related path, specific wavelengths in optical fibers supporting the EPSrelated
path, and the like), and the like, as well as combinations thereof. In
one embodiment, for example, path information associated with other types of
paths may include some or all of the path information described with respect
to EPC paths, other types of path information (which may depend on the other
types of paths), and the like, as well as combinations thereof. In such
embodiments, the path information associated with a path may include any
other suitable information, which may vary for different types of paths, for
different paths of the same type, and the like.
In one embodiment, CE 223 may support additional processing in order
to support management functions provided by one or more of the tools (i.e.,
ANT 225, AUT 226, TT, 227, and FMT 228). In one embodiment, CE 223
may process discovery information stored in DD 222 and/or path correlated
transport element information stored in PD 224 in order to support
management functions provided by one or more of ANT 225 (e.g., for
providing analysis functions), AUT 226 (e.g., for providing audit functions), TT
227 (e.g., for providing trace functions), and FMT 228 (e.g., for providing
enforcement functions). In one embodiment, CE 223 may process
management function information generated by one or more of the tools in
support of management functions provided by one or more of the tools (e.g.,
where CE 223 processes information on behalf of one or more of the tools for
use by that tool or for use by one or more of the other tools in providing
management functions). The CE 223 may provide any other correlation
functions suitable for providing and/or supporting the various management
functions depicted and described herein.
In various embodiments, paths are grouped together in a logical
structure according to a common element, sub-element, link, service,
provider, third party service lessee and so on.
A bundle may be a logical grouping of paths that share a common
element, such as a common end point element, start point element and the
like. In this context, bundling is useful to identifying all of the paths that will be
impacted by the failure of the common element. That is, a number of paths
terminated at a particular network element from a plurality of other network
elements of a common type may be defined as a bundle or group. Examples
include "all of the eNodeB elements in communication with SGWx" where
SGWx represents a specific SGW); or "all of the SGWs communicating with a
PGWx" (where PGWx represents a specific PGW). These and other bundles
or groups may be defined to enable rapid identification of network elements or
sub-elements that are similarly situated in terms of a common network
element or sub element to which they are connected.
A bundle may be generalized as a logical grouping of paths that share
any common structure or entity, such as a group of paths associated with a
common billing entity, a specific network provider, a specific service offering
and the like. In this context, bundling is useful in identifying the specific
infrastructure (and its usage) associated with a billing entity, network provider,
service offering and the like. This is especially useful within the context of
leasing network resources to a third party under a service level agreement
where it is necessary to both monitor usage and support the services
purchased by the third party. Examples include "all the mobile services that
are anchored in an eNodeB that services a specific Access Point Name (APN)
(such as a telecommunications or cable company); or "all of the SGWs or
PGWs that service a particular service provider." In a service provider
example, a third party service provider may lease space at one or more
eNodeBs to provide service to its mobile users (e.g., via specific reserved
frequencies on each of a plurality of eNodeBs).
The correlated information is stored in one or more databases to
facilitate rapid retrieval by network operations personnel and/or other users,
such as the Path Database (PD) 224.The PD 224 stores path correlated
transport element information determined by CE 223. The PD 224 may store
the path correlated transport element information and associated path
information in any suitable format. The PD 224 provides a repository of path
and network element related information for use by one or more of ANT 225,
AUT 226, TT 227, and FMT 228 for providing their respective management
functions.
FIG. 3 depicts a high-level block diagram illustrating a discovery and
correlation process performed by the exemplary management system of
FIG. 2 . As depicted in FIG. 3 , and described herein with respect to FIG. 2 , the
discovery and correlation process 300 performed by exemplary MS 140 is
performed by DE 221 , DD 222, CE 223, and PD 224. The DE 221 discovers
information associated with LTE network 110 and stores discovery information
in DD 222, DE 221 and DD 222 provide discovery information to CE 223 for
use by CE 223 in correlating the discovery information for identifying paths of
the LTE network and storing the path correlated transport element information
associated with the identified paths of the LTE network in the PD 224. The
discovery and correlation process 300 of FIG. 3 may be better understood by
way of reference to FIG. 2 .
As depicted in FIG. 2 , ANT 225, AUT 226, TT 227, and FMT 228 each
provide various management functions for LTE network 110 .
The ANT 225 structures EPS elements of an LTE network into Mobile
Services. In one embodiment, the EPS elements include the EPS network
elements (e.g., eNodeBs, SGWs, PGWs, MMEs, the PCRF, and/or any other
EPS-related network elements) and the EPS-related interconnectivity
between the EPS network elements (e.g., S* sessions, G* sessions, and the
like). For example, with respect to LTE network 110 of FIG. 1, the ANT 225
structures EPS elements of the LTE network 110 into Mobile Services (e.g.,
eNodeBs 111, SGWs 112, PGW 113, MMEs 114, PCRF 115 , S* sessions,
and the like). In this manner, a Mobile Service is a representation of EPS
network elements and EPS-related interconnectivity between the EPS
network elements.
The Mobile Service stores for each network element a list of all of the
other network elements connected to it. Thus, for a particular eNodeB, the
Mobile Service stores a list including the SGW and PGW to which the eNodeB
communicates. Similarly, for a particular SGW, the mobile service stores a
list including the eNodeBs and PGW to which the SGW communicates. Other
common or anchor elements may be used to form such bundles. These
examples contemplate, respectively, a particular eNodeB as an anchor or
common element and a particular SGW as an anchor or common element.
Other anchors or common elements may be defined within the context of the
various embodiments.
The ANT 225 may structure EPS elements of LTE network 110 into
Mobile Services using any suitable information (e.g., using the underlying
transport elements correlated to EPS-related paths from PD 224, by
processing discovery information from DD 222, and the like, as well as
combinations thereof). In one embodiment, ANT 225 is configured to
automatically create Mobile Services as areas of the LTE network 110 are
discovered by DE 221 .
Analyzer Function/Tool.
FIG. 4 depicts an exemplary Mobile Service supported by the LTE
network of FIG. 1. Specifically, FIG. 4 depicts an exemplary communication
system 400 that is substantially identical to exemplary communication system
100 of FIG. 1, except that FIG. 4 further depicts a path associated with a
Mobile Service 402.
As depicted in FIG. 4 , the exemplary Mobile Service 402 includes
eNodeB 111 SGW 112i, PGW 113 , the S1-u interface between eNodeB
and SGW 112i , the S5/S8 interface between SGW 2i and PGW 3 ,
the SGi interface between PGW 113 and IP networks 130, the S 1-MME
interface between eNodeB 111 and MME 114i , the S 1-u interface between
SGW 112 and MME 11 , and the S7 interface between PGW 113 and
PCRF 115 . The exemplary Mobile Service 402 is marked on FIG. 4 using a
solid line representation. Optional embodiments may include MME 1 and
PCRF 115 , for example.
The ANT 225 enables the service provider of an LTE network to have a
current view of the status of the service delivery distribution network from the
IP Core network through the eNodeB access nodes at the edge of the LTE
network. The ANT 225 enables the service provider of an LTE network to
monitor the status of the LTE network at a logical level. This is advantageous
for efficiently diagnosing problems or potential problems which may impede
delivery of mobile traffic within the LTE network. For example, equipment of
the LTE network may be operational, but misconfiguration on an SGW
instance might be blocking delivery of mobile traffic.
The ANT 225 enables the service provider of an LTE network to quickly
and easily identify which components of the LTE network 110 are responsible
for problems or potential problems identified at the Mobile Service level of
LTE network 110, e.g., by identifying which EPS element(s) are responsible
for the problem or potential problem, and then further identifying which
component(s) of the responsible EPS element(s) are responsible for the
problem or potential problem.
For example, this may include identifying, at the Mobile Service level, a
specific EPS network element that is responsible for the problem, and then
drilling down on the EPS network element that is responsible for the problem
to identify components of the EPS network element that are responsible for
the problem. The components of EPS network elements may include any
components of the EPS network elements (e.g., traffic cards, control cards,
ports, interfaces, processors, memory, and the like).
For example, this may include identifying, at the Mobile Service level, a
specific EPS interconnection (e.g., S* sessions, G* sessions, and the like) that
is responsible for the problem, and then drilling down on the EPS
interconnection that is responsible for the problem to identify components of
the EPS interconnection that are responsible for the problem. The
components of EPS interconnections may include any components. It will be
appreciated that the EPS interconnections described with respect to ANT 225
correspond to the EPS-related paths described with respect to CE 223 and
correlated to underlying transport elements such as provided via PD 224.
Thus, the components of EPS interconnections may include components
associated with EPS-related paths as discussed with respect to the CE 223
and PD 224 (i.e., the transport elements and components that provide the
underlying communications capability for the EPS-related paths).
For example, the components of EPS-related paths may include S*
reference points forming the endpoints of the EPS-related paths, network
elements (e.g., routers, switches, and the like), components of network
elements (e.g., line cards, ports, interface, and the like), communication links
between network elements, logical paths on communication links between
network elements (e.g., such as specific MPLS paths supporting the EPSrelated
path, specific wavelengths in optical fibers supporting the EPS-related
path, and the like), and the like, as well as combinations thereof.
The ANT 225 may drill down on EPS elements in any suitable manner,
which may depend on the type of EPS element for which component
information is desired (e.g., using discovery information stored in DD 222 for
determining components of EPS network elements, using the path correlated
transport elements, sub-elements, systems and other information stored in PD
224 for determining components of EPS-related paths, and the like, as well as
combinations thereof).
The ANT 225 may perform one or more management functions for
Mobile Services determined by ANT 225.
In one embodiment, ANT 225 may collect statistics associated with
Mobile Services (e.g., end-to-end statistics associated with the Mobile
Service, statistics associated with individual components and/or subsets of
components of the Mobile Service, and the like, as well as combinations
thereof). The ANT 225 may analyze collected statistics for identifying the
presence of congestion, or impending presence of congestion, associated
with Mobile Services. The ANT 225 may proactively determine, on the basis
of such analysis, solutions for resolving or preventing congestion.
In one embodiment, ANT 225 may initiate audits for verifying Mobile
Services (e.g., for ensuring that the view of Mobile Services currently
maintained by ANT 225 is accurate and does not need to be updated, for use
in updating the view of Mobile Services where such updating is required, and
the like, as well as combinations thereof). The ANT 225 may analyze the
results of such audits for determining the manner in which the LTE network
has been built (or discovered) in order to find topological and/or configuration
errors within the LTE network and, further, for suggesting associated
improvements.
In one embodiment, ANT 225 may initiate Operations, Administration,
and Maintenance (OAM) tests for Mobile Services. In this embodiment, the
OAM tests may be initiated in any suitable manner. For example, OAM tests
may be initiated manually, automatically in response to any suitable trigger
conditions (e.g., per a fixed schedule, in response to detecting an indication of
a fault associated with a component which may form part of the Mobile
Service, and the like), and the like, as well as combinations thereof). For
example, OAM tests may be generated for a specific Mobile Service and then
scheduled at different times of the day to monitor the status of the Mobile
Service. The ANT 225 may be configured to use the results of such OAM
tests to identify areas of high contention within the LTE network 110 .
The ANT 225 may perform fault analysis for Mobile Services. In one
embodiment, for example, in response to detecting an event on one of the
sub-components of a Mobile Service(s), ANT 225 may determine the effect of
the event on the Mobile Service(s). The ANT 225 may identify any events
which may be associated with components of Mobile Services (e.g., EPS
network elements, EPS interface, and the like). The ANT 225 may identify
events in any suitable manner using messages associated with any suitable
management protocol(s), such as SNMP traps, TL1 messages, and the like.
The ANT 225 may categorize detected events based on their importance. The
importance may be determined based on any suitable parameter or
parameters (e.g., the location of the event, the type of event, and the like, as
well as combinations thereof). For example, an event associated with an
eNodeB may be deemed to be less important than an event associated with a
PGW, since PGWs support a much larger number of users than eNodeBs.
The ANT 225 may initiate generation of imagery adapted for being
displayed to provide network technicians of the service provider with a visual
representation of the event (e.g., location of the event, scope of the event,
and the like).
The ANT 225 also may initiate one or more OAM tests (e.g., ping,
traceroute, and the like) for the Mobile Service(s) associated with the event, in
order to determine additional information providing a better understanding of
the scope and impact of the event. The ANT 225 may initiate such OAM tests
manually and/or automatically (e.g., as part of error detection, as part of a
scheduled initiation of OAM tests, and the like, as well as combinations
thereof).
The ANT 225 may perform any other suitable management functions
associated with Mobile Services determined by ANT 225.
Generally speaking, the analyzer tool may be invoked after the network
manager discovers the network elements and their connections as previously
described. The service aware manager identifies the LTE type network
elements, such as PGW, SGW, eNodeB, MME, PCRF, SGSN and the like.
Of primary interest are the PGW, SGW and eNodeB. Between these network
elements are EPS paths having associated reference points on the network
elements, where the EPS paths / reference points are denoted as S 1-u, S5,
SGi and so on. Thus, stored in a database is a collection of modular
components, of type "network element" for the PGW, SGW, eNodeB and the
like, or type "connector" for the EPS paths.
After discovering the network elements and connectors, the service
aware manager defines a plurality of Mobile Services by connecting or
concatenating instances of the two types of modular components (i.e.,
network elements and connectors), such as the sequence of network
elements and connectors between a customer served via a specific eNodeB
and a data stream or other service received from the IP core network at the
PGW. Thus, in one embodiment, a mobile service comprises a structure or
wrapper containing a concatenated sequence of network elements and
connectors. A Mobile Service may be defined in terms of a particular
customer, a particular eNodeB, a particular APN and so on. A mobile service
may include one or more instances of an EPS on a network element, such as
one or more of an SGW or a PGW on a single or common network element.
After defining the Mobile Services, the Mobile Services may be
analyzed or tested. Such testing may be directed to the components forming
a Mobile Service, the endpoints associated with the Mobile Service and the
like. Such testing may be directed to specific portions of specific components
or endpoint forming the Mobile Service.
In one embodiment, individual Mobile Services or groups of Mobile
Services are analyzed by collecting statistics from each of the Mobile Service
modular components forming the particular individual or groups of Mobile
Services. That is, a Mobile Service analysis request (generated manually or
automatically) is interpreted by the management system as a request to
gather statistical information pertaining to each of the modular components
(e.g., network elements and connectors) forming a Mobile Service.
For example, assume that a Mobile Service comprises a plurality of
network elements and connectors arranged in the following sequence:
"eNodeB, S1-u, SGW, S5, PGW'. In response to an analysis request of the
Mobile Service, the analysis tool gathers statistical values associated with
each of the components forming the Mobile Service (i.e., the elements and
connectors) to provide thereby data describing, illustratively, the operational
status of the Mobile Service, the components forming a Mobile Service, the
endpoints of the Mobile Service and/or other information pertaining to the
Mobile Service.
In one embodiment, OAM tests such as ping tests (e.g., ICMP ping
test), trace route tests and the like may be run upon the Mobile Service to
ensure that the components forming a Mobile Service are operational and not
degraded, that connectivity between the various components exists, that the
test results conform to expected test results such as based upon a rolling
average or other historical/statistical representation of prior test results. In
this manner, an OAM test ensures that Mobile Services are operational and,
further, obtains statistical information useful in predicting degradations or
failures of one or components forming the Mobile Service. For example, an
OAM test may comprise the execution of specific Mobile Service tests every
15 minutes, two hours or other predetermined time period.
All tests performed on the Mobile Service or Mobile Service portions
will return some result. The result should fall within an acceptable or
expected results range. Results returned outside of this range (or not
returned at all) are likely indicative of an immediate or existing problem with
the Mobile Service components, subcomponents or endpoints. For example,
a ping test indicating a 1 second delay time between a PGW and an eNodeB
may be indicative of a problem in a Mobile Service between these two
endpoints. By sequentially "pinging" each of the network elements in the
connection, components forming a Mobile Service proximate the location of
the problem may be found quickly (e.g., the component after which the return
result changes from a normal low delay value to the 1 second delay time).
Changes in the returned result of one or more tests over time may also
be indicative of a problem that exists or a problem that will exist in the future.
By tracking the results of these tests over time, and correlating the test results
to degradations and/or failures over time, operating characteristics associated
with impending degradations and/or failures may be predicted.
In one embodiment, the analysis tool automatically instantiates tests or
suites of tests in response to specific operating characteristics of the network,
manual requests for test suites, automatic requests for test suites and the like.
A test suite comprises a plurality of predefined tests to be performed upon
one or more Mobile Services either once or periodically in which specific test
results ranges are expected. Test suites log the various parameters
associated with the tests, the network element and connection components
tested, and any ancillary data that is desired (e.g., other network operating
characteristics such as bandwidth utilization, bit error rate and the like that are
useful in correlating test result data changes over time to specific problems).
The tests or suites of tests are invoked depending upon the severity of
alarm, the importance of the network component raising the alarm, the type of
alarm and so on. As an example, an alarm raised by an eNodeB to its Mobile
Service is less important than a similar alarm raised by a PGW. Alarm
triggers may be used in various embodiments to invoke tests or suites of
tests. Generally speaking, a trigger condition may be associated with a
starting point parameter (e.g., an initial network element or communication
link associated with the trigger condition) and/or a task parameter (e.g., one or
more tasks forming at least a portion of an appropriate response to the trigger
condition).
Thus, the logical representation of modular components such as
"network element" and "connector" to form Mobile Services enables precise
auditing, analysis and tracing functions to be implemented within the context
of the various embodiments.
FIG. 5 depicts one embodiment of a method for performing an analysis
function. Specifically, FIG. 5 depicts a flow diagram of a method 500 adapted
for use in managing a network comprising a plurality of network elements.
At step 510, the method retrieves, for each of the network elements to
be managed within the network, respective configuration information, status
information and connections information.
At step 520, using the retrieved information, the connections or links by
which data is communicated between a portion of or all of the network
elements are determined.
At step 530, data representing at least a portion of the determined
network element connections of the retrieved network element information is
stored in a computer readable storage medium, such as a database or other
memory element.
At step 540, the elements within the network that are necessary to support
each of a plurality of services are identified, the identified network elements
including this determination including at least managed network elements and
communications links.
Although primarily described with respect to embodiments in which
such management functions are performed by ANT 225, it will be appreciated
that any of these management functions may be performed by one or more of
other engines and/or tools of MS 140, one or more other management
systems in communication with MS 140 (omitted for purposes of clarity), and
the like, as well as combinations thereof.
Auditor Function/Tool.
The AUT 226 provides an audit capability for auditing LTE network
110 . The AUT 226 enables proactive auditing of network infrastructure of LTE
network 110 for identifying and handling network faults or potential network
faults that are impeding or may impede end user traffic. Various
embodiments of the AUT 226 are described in more detail in co-pending US
Patent Application No. (Attorney Docket No.
ALU/806271 .entitled "Method and Apparatus for Auditing 4G Mobility
Networks"), which is incorporated herein by reference in its entirety.
Briefly, the AUT 226 supports quick detection of network faults or
potential network faults, impact analysis for determining the impact of faults or
potential impact of potential network faults, and rectification of any network
faults or potential network faults. The AUT 226 provides an ability to perform
in-depth network health or sanity checks on LTE network 110 at any
granularity level, e.g., for checking the health of ports, line cards, physical
connectivity, logical connectivity, S* reference points, S* sessions, network
paths, end-to-end mobile sessions of end users, and the like, as well as
combinations thereof. The AUT 226 provides significant advantages in
managing LTE networks, as such networks are inherently complex and, thus,
highly susceptible to network faults that are often difficult to correlate to
mobile subscriber data that has been packetized for transport over an IP
network traversing multiple network elements that utilize different transport
technologies and applied QoS policies.
In one embodiment, AUT 226 supports auditing of interconnectivity
within LTE network 110 . The auditing of interconnectivity may include
proactively monitoring for connectivity, testing connectivity, and performing
like auditing functions.
In one embodiment, auditing of interconnectivity within the LTE network
110 includes auditing interconnectivity between eNodeBs and EPC nodes of
LTE network 110 (e.g. , between eNodeBs 111, SGWs 112 , PGW 113 , MMEs
114 , and PCRF 115 , via the associated S* interfaces). In this embodiment,
auditing of interconnectivity within the LTE network 110 includes auditing one
or more EPS-related paths of LTE network 110 .
The AUT 226 is capable of running tests on demand or on a schedule
to determine whether the structure supporting the various paths is operating
appropriately, such as within predefine operational parameters indicative of
appropriate operation (e.g., not over utilized, not too high a BER and so on).
In one embodiment, a preferred starting point for invoking the AUT 226
is the reference points terminated at the SGW (rather than at an eNodeB). It
is known via the discovery/correlation processes that there are particular
paths, connections or services between the SGW and the eNodeBs it serves.
It is further known whether the paths, connections or services traverse other
equipment, such as routers, switches and the like.
The AUT 226 may be used to test numerous parameters associated
with the underlying infrastructure and or the path. Moreover, the testing may
be performed in an incremental fashion from a first or initial reference point,
where each subsequent infrastructure device within the path is subjected to
testing from AUT 226. One simple test is to determine if the input ports and/or
output ports associated with the infrastructure devices supporting the path are
functioning or not functioning. This may be accomplished by sending query
messages to each infrastructure device, by sending a test message or vector
through the path and examining the test message or vector and each of a
plurality of input/output ports.
In one embodiment, user guided processing by AUT 226 is provided.
In this embodiment, user hints or other indicia of likely infrastructure topology
is provided, such as where a third party/unmanaged portion of the network
requires testing. In this context, a hint may comprise a suggestion or likely
topology utilized by the third party within its portion of the network.
As described herein, in general, an EPS-related path is a path that is a
transport mechanism that represents a peering relationship between two EPS
reference points, where an EPS reference point is a termination point for any
node of LTE network 110 that implements one or more of the protocols
present in the 4G specification (e.g., using GTP, PMIP, or any other suitable
protocols, and the like, as well as combinations thereof). As depicted and
described herein, EPS reference points may include: for an eNodeB (S1 -u,
S 1-MME, X2, and the like); for an SGW 112 (S1 -u, S5/S8, S 11, Gxs, and the
like); for a PGW (S5/S8, SGi, SGx, S7, S2a, S2b, S2c, and the like); for an
MME (S1-MME, S 11, S 10 , and the like); and for a PCRF (S7). Thus, EPSrelated
paths correspond generally to the various S* sessions between the
eNodeBs and EPC nodes (e.g., a path between an eNodeB 111 and an SGW
112 in the case of S 1-u reference points, a path between an SGW 112 and
PGW 113 in the case of S5/S8 reference points, a path between an eNodeB
111 and an MME 114 in the case of S 1-MME reference points, and the like).
As described herein, EPS-related paths of LTE network 110 may be
supported using any suitable underlying communications technologies. For
example, an S 1-u path between an eNodeB 111 and SGW 112 may be
supported using a full IP/MPLS network which may include routers, switches,
communication links, protocols, and the like. For example, an S5/S8 path
between an SGW 112 and a PGW 113 may be supported using an IP mesh
backhaul network that includes edge routers, core routers, communication
links, protocols, and the like. The S* paths each may be supported using any
suitable underlying communication technologies. In this embodiment, the
auditing may include correlating different interconnection technologies and
transport layers which support the respective S* sessions between EPC
nodes of LTE network 110 .
FIG. 6 depicts an exemplary EPS-related path of the LTE network of
FIG. 1. As depicted in FIG. 6 , the exemplary EPS-related path 600 is an S 1-u
path between an eNodeB and a SGW (illustratively, between eNodeB 1112
and SGW 1122) . The exemplary EPS-related path 600 includes an S 1-u
interface 602A on eNodeB 1112 and an Sl-u interface 602z on SGW 1122. The
exemplary EPS-related path 600 is supported using an IP/MPLS backhaul
network 610, which is a mesh network including a plurality of service aware
routers (SARs) and/or service aware switches (SASs) 612. The SARs/SASs
612 include ports 6 13 , which typically have administrative and operational
states associated therewith. The SARs/SASs 612 are interconnected via a
plurality of communication links 614. It will be appreciated that exemplary
EPS-related path 600 may be provided using any other communications
technologies suitable for supporting paths between elements of LTE network
110 .
The auditing of an EPS-related path may be performed in any suitable
manner. In one embodiment, for example, auditing of an EPS-related path
may include the steps of: (a) determining a current configuration of the path
(e.g., performing processing of discovery information in DD 222 to determine
the current configuration, requesting CE 223 to determine the current
configuration, and the like, as well as combinations thereof), (b) obtaining the
last known configuration of the path (e.g., from PD 224 information or any
other suitable source of such information), (c) verifying the current
configuration of the path against the last known configuration of the path, (d) if
the current and last known configurations of the path match, initiating a test of
the path at the LTE protocol level (e.g., initiating a GTP ping test, an MPIP
ping test, or any other suitable test or tests depending on the protocol(s) being
used to support the path), (e) if the protocol-level test of the path is
successful, verifying the configuration of the IP interfaces, which may include
verifying routing configuration, testing transport connectivity between the IP
interfaces associated with the EPS reference points of the path at the IP level
(e.g., using ICMP pings or other suitable testing capabilities), and the like, (f) if
configuration of the IP interfaces is successful, verifying the administrative
states of the ports, and (g) if the administrative states of the ports are verified
successfully, verifying the operational states of the ports.
Tracer Function/Tool.
The TT 227 is configured to provide a mobile session trace capability.
The mobile session trace capability enables a path of a mobile session of a
UE to be traced through a wireless network. Various embodiments of the TT
227 are described in more detail in co-pending US Patent Application No._
(Attorney Docket No. ALU/806254, entitled "Method and
Apparatus for Tracing Mobile Sessions"), which is incorporated herein by
reference in its entirety.
Briefly, the TT 227 enables a determination of the path of a mobile
session through a wireless network and, optionally, determination of additional
information associated with the mobile session. The mobile session trace
capability enables wireless service providers to perform management
functions based on the determined path of the mobile session through the
wireless network.
The TT 227 is configured to determine the path of mobile sessions
through LTE network 110. The TT 227 also may perform other functions
associated with mobile sessions determined by TT 227, such as determining
additional information associated with the mobile sessions, performing
management functions for the mobile sessions, and the like, as well as
combinations thereof.
The TT 227 may provide only the mobile session trace capability, or
may provide the mobile session trace capability in addition to one or more
other management functions. The TT 227 is configured to determine the path
of a mobile session through a wireless network. The TT 227 also may be
configured to perform additional functions for mobile sessions. For example,
the TT 227may be configured to determine additional information associated
with mobile sessions, to correlate mobile session information to other
information, to perform various management functions for mobile
sessions(e.g., one or more of monitoring mobile sessions, diagnosing
problems with mobile sessions, anticipating problems with mobile sessions,
correcting problems with mobile sessions, and performing like management
functions for mobile sessions), and the like. The TT 227 is optionally
configured or adapted to perform various combinations of the functions
described herein.
Although primarily depicted and described with respect to
embodiments in which the functions of the mobile session trace capability are
performed by TT 227, it will be appreciated that various functions of mobile
session trace capability and/or in support of the mobile session trace
capability may be performed by TT 227 in combination with one or more other
engines and/or tools of MS 140, by one or more other engines and/or tools of
MS 140 for providing information to TT 227 for use by TT 227 in providing
various functions of the mobile session trace capability, and the like, as well
as combinations thereof.
The TT 227 may be configured or adapted to perform broader
management functions using information associated with mobile session path
traces, such as diagnosing broader network problems, anticipating broader
network problems, performing network optimization actions, and other
management functions.
Fairness Manager Function/Tool.
The FMT 228 provides various fairness management mechanisms
adapted to controlling usage of network resources by mobile subscribers.
Various embodiments of the FMT 228 are described in more detail in co
pending US Patent Application No. (Attorney Docket No.
ALU/806290, entitled "Method and Apparatus for Managing Mobile Resource
Usage"), which is incorporated herein by reference in its entirety.
Briefly, the FMT 228 enforces appropriate resource (e.g., bandwidth)
usage by customers, such as defined by service level agreements (SLAs) and
the like. The fairness manager enforces appropriate bandwidth usage by any
of a variety of enforcement mechanisms. The fairness manager is operative
to enforce appropriate resource consumption levels associated with various
users, groups of users, customers, third party network purchasers and the
like, whether those levels are defined by agreement or acceptable practice.
The FMT 228 operates, in various embodiments, to identify one or
more network elements experiencing congestion or likely to experience
congestion in the near future.
In one embodiment, FMT 228 identifies congestion of a network
element via detection of alarms (e.g., alarms associated with the network
element, alarms associated with paths connected to the network element, and
the like), via control messages received from one or more other modules
(e.g., other tools of MS 140, other management systems, or any other suitable
source(s) of such control messages), and the like, as well as combinations
thereof. In one embodiment, FMT 228 receives alarms that are triggered
based on active monitoring of network performance.
In one embodiment, FMT 228 identifies congestion of a network
element in response to reports of service problems received from mobile
subscribers. For example, a mobile subscriber calling to complain about poor
Quality of Service (QoS) or a Quality-of-Experience (QoE), may provide the
telephone number of the UE, which will be used by the network manager to
look up the IMSI number associated with the UE, which may then be captured
at MS 140 and used by MS 140 to determine the network elements that are or
were supporting sessions for that UE. In one such embodiment, TT 227 is
invoked in order to trace the mobile session path of the UE of complaining
mobile subscriber (e.g., based on the IMSI of the UE, as described with
respect to TT 227), which provides an indication as to the network elements
that are or were supporting sessions for the UE of the complaining mobile
subscriber. In one embodiment, one or more of the mechanisms of FMT 228
is configured to communicate with one or more other management systems
for receiving information adapted for use in providing the various enforcement
functions.
Examples of Environments Supporting the Various Embodiments
Generally speaking, various embodiments enable a user, such as a
user in a network operations center (NOC), utilizing a computer terminal or
other user workstation with a graphical user interface (GUI) interact with the
management system/software and thereby to "drill down" deeper from upper
to lower hierarchical level path elements by displaying lower level path
elements associated with upper level path elements selected by a user via a
user interface.
In one embodiment, mobile session path information is displayed by
generating a "sub-map" including only the network components that support
the mobile session and displaying the generated sub-map. For example,
where the graphical display of the wireless network includes many eNodeBs,
SGWs, and PGWs, the sub-map for a mobile session will include only one of
each of those elements, as well as the sessions between each of those
elements, thereby highlighting which network elements of the wireless
network are supporting the mobile session.
In this example, the sub-map may be displayed in any suitable manner
(e.g., simultaneously in a window in a different portion of a window in which
the wireless network is displayed, in a new window opened for purposes of
displaying the sub-map, and the like). In this example, as in the previous
example, the mobile session path, or even components and sub-components
of the mobile session path (e.g., physical equipment, physical communication
links, sub-channels on physical communication links, and the like), may be
selectable such that, when selected by the user, the user is presented with
additional mobile session path information associated with the mobile session.
From such examples, it will be appreciated that display of additional
information associated with a mobile session path may be provided in any
suitable manner (e.g., refreshing within the display window to include mobile
session path information, opening a new window including mobile session
path information, and the like, as well as combinations thereof).
Implementations of the various methods optionally yield logical and/or
physical representations of one or more paths, underlying transport elements
supporting the one or more paths, as wells as various protocols, hardware,
software, firmware, domains, subnets, network element and/or subelement
connections as discussed herein. Any of these physical and/or logical
representations may be visually represented within the context of a graphical
user interface (GUI). Moreover, the various interactions and correspondences
between these physical and/or logical representations may also be visually
represented, included representations limited to specific criteria, such as
those representations "necessary to support a path", "necessary to support a
client/customer", "associated with a single client/customer" and so on. Such
graphical representations and associated imagery provide infrastructure views
(i.e., from the perspective of one or more transport elements) or services
views (i.e., from the perspective of one or more services) of the network in
either a static or dynamic manner.
A computer suitable for use in performing the functions described
herein may include, illustratively, a processor element (e.g., a central
processing unit (CPU) and/or other suitable processor(s)), a memory (e.g.,
random access memory (RAM), read only memory (ROM), and the like), a
management module/processor, and various input/output devices (e.g., a user
input device (such as a keyboard, a keypad, a mouse, and the like), a user
output device (such as a display, a speaker, and the like), an input port, an
output port, a receiver/ transmitter (e.g., network connection or other suitable
type of receiver/transmitter), and storage devices (e.g., a hard disk drive, a
compact disk drive, an optical disk drive, and the like)). In one embodiment,
computer software code associated with methods for invoking the various
embodiments can be loaded into the memory and executed by processor to
implement the functions as discussed herein above. The computer software
code associated with methods for invoking the various embodiments can be
stored on a computer readable storage medium, e.g., RAM memory, magnetic
or optical drive or diskette, and the like.
It should be noted that functions depicted and described herein may be
implemented in software and/or in a combination of software and hardware,
e.g., using a general purpose computer, one or more application specific
integrated circuits (ASIC), and/or any other hardware equivalents.
It is contemplated that some of the steps discussed herein as software
methods may be implemented within hardware, for example, as circuitry that
cooperates with the processor to perform various method steps. Portions of
the functions/elements described herein may be implemented as a computer
program product wherein computer instructions, when processed by a
computer, adapt the operation of the computer such that the methods and/or
techniques described herein are invoked or otherwise provided. Instructions
for invoking the inventive methods may be stored in tangible fixed or
removable media, transmitted via a data stream in a tangible or intangible
broadcast or other signal bearing medium, and/or stored within a memory
within a computing device operating according to the instructions.
Although primarily depicted and described herein with respect to
embodiments in which the management capability is used for managing an
LTE wireless network, it will be appreciated that the management capability
may be used for managing other types of wireless networks, including, but not
limited to, other types of 4G wireless networks, 3G wireless networks, 2.5G
wireless networks, 2G wireless networks, and the like, as well as
combinations thereof.
In one embodiment, for example, in which the management capability
is used to manage a Code Division Multiple Access (CDMA) 2000 Evolution -
Data Optimized (EVDO) network, the management capability may support
management of the network from the IP core network to the Base Transceiver
Station (BTS) to which the UE connects.
In one embodiment, for example, in which the management capability
is used to manage a Universal Mobile Telecommunications System (UMTS)
network, the management capability may support management of the network
from the IP core network to the eNodeB to which the UE connects.
In one embodiment, for example, in which the management capability
is used to manage a General Packet Radio Service (GPRS) network, the
management capability may support management of the network from the IP
core network to the Base Transceiver Station (BTS) to which the UE
connects.
It will be appreciated that, since the management capability may be
used to manage different types of wireless networks that employ different
types of network elements, the LTE-specific terminology used herein in
describing the management capability within the context of an LTE network
may be read more generally. For example, references herein to PGWs of the
LTE network (and, similarly, PDSNs in CDMA2000 EVDO networks, SGSNs
in UMTS/GPRS networks, and the like) may be read more generally as core
network gateways. For example, references herein to SGWs of the LTE
network (and, similarly, RNCs in CDMA2000 EVDO and UMTS networks,
BSCs in GPRS networks, and the like) may be read more generally as radio
network controllers. For example, references herein to eNodeBs of the LTE
network (and, similarly, BTSs in CDMA2000 EVDO and GPRS networks,
eNodeBs in UMTS networks, and the like) may be read more generally as
wireless access nodes. Similarly, other LTE-specific terminology used herein
in describing the management capability within the context of an LTE network
also may be read more generally.
In various embodiments, enhanced services are provided using one or
both of the 7750 Service Router or 7705 Service Aggregator Router (SAR),
both of which are manufactured by Alcatel-Lucent of Murray Hill, NJ.
The 7750 Service Router is adapted to facilitate and support paths
between a large number of eNodeBs and a SGW, or between one or more
7705 SARs and a SGW.
The 7705 SAR is adapted to aggregate multiple eNodeBs into one
focal point and relays the traffic back to a 7750 Service Router or a SGW.
That is, 7705 SAR concentrates and supports traffic/ paths between the
aggregated eNodeBs and either or both of a 7750 Service Router or a SGW.
Either of the 7750 Service Router and 7705 SAR may be included
within the various network topologies discussed above with respect to the
various figures. For example, the 7750 Service Router may be used to
implement the service aware routers/switches of the various Figures.
Moreover, the various networks described in the Figures may be modified to
include one or more 7705 SARs to aggregate multiple eNodeBs connected to
the service aware routers/switches.
A network manager according any of the various embodiments may be
implemented using the Model 5620 Service Aware Manager (SAM)
manufactured by Alcatel-Lucent. The 5620 SAM implements various
management functions suitable for use in, for example, a network operations
center (NOC) supporting one or more a telecommunications networks, such
as wireless telecommunications networks. The 5620 SAM provides an up to
date view of each of the elements and sub-elements forming the managed
network. All of these elements may be discovered by the 5620 SAM as
discussed in more detail above.
A general implementation for network operators transitioning from a
prior network management system to a service aware management system
may comprise, illustratively, ( 1) adapting an existing network structure to
include new functional elements to accomplish changing goals/needs of
customers, such as adding new functional elements such as the 7750 Service
Router and/or 7705 SAR switching elements between one or more SGWs and
at least a portion of their respective eNodeBs; (2) discovering the various
configuration, status/operating and connections information associated with all
the network elements, sub-elements and links forming the network; (3)
correlating the network infrastructure to the various paths supported within the
network; and (4) managing the network infrastructure using the path-based
management tools discussed herein.
Although various embodiments which incorporate the teachings of the
present invention have been shown and described in detail herein, those
skilled in the art can readily devise many other varied embodiments that still
incorporate these teachings.
What is claimed is:
1. A method for managing a network comprising a plurality of network
elements, the method comprising:
retrieving, for each of the network elements to be managed within the
network, respective configuration information, status information and
connections information;
determining, using the retrieved information, at least a portion of the
connections by which data is communicated between the network elements to
be managed; and
storing, in a computer readable storage medium, data representing at
least a portion of the retrieved network element information and determined
network element connections.
2 . The method of claim 1, further comprising:
identifying the elements within the network that are necessary to
support each of a plurality of mobile services, the necessary elements
including at least managed network elements and communications links.
3 . The method of claim 2 , wherein the mobile services comprise Evolved
Packet Solution (EPS) related paths.
4 . The method of claim 1, wherein the connections information includes
address information associated with one or both of packets received by a
network element and packets transmitted by the network element, wherein the
step of determining connections comprises inferring that a connection exists
between two network elements using packet address information, wherein the
step of determining is iteratively performed for each of the managed network
elements.
5 . The method of claim 2 , wherein the identified elements necessary to
support each of a plurality of mobile services further include at least one of
necessary portions of a necessary network element and necessary portions of
a necessary communication link, wherein an element is identified as
necessary to a service if a failure or degradation of the element impacts the
service.
6 . The method of claim 2 , wherein:
the network element information is retrieved by a discovery engine
within a network management system (NMS); and
the network element connections and necessary service support
elements are determined by a correlation engine within the NMS;
the NMS further includes an analyzer tool adapted to automatically
analyze a service instance using statistical operating data gathered from each
of the necessary service support elements.
7 . The method of claim 2 , further comprising:
selectively bundling into a mobile service group each of a plurality of
mobile services according to a common mobile service parameter, the
common mobile service parameter comprising one or more of a common
necessary element, a common service type, a common user type, a common
quality of service (QoS), a common service provider, a common Access Point
Name (APN), a common eNodeB, a common SGW and a common PGW.
8 . The method of claim 1, further comprising:
using the retrieved network element information and determined
network element connections visually represent at least a portion of the
infrastructure of the network within a graphical user interface (GUI);
identifying the managed network elements and communications links
necessary to support each of a plurality of services; and
using the identified managed network elements and communications
links necessary to support at least one service, visually representing the
corresponding at least one service within the graphical user interface (GUI);
wherein the GUI, in response to user input, selectively presents
imagery of one or both of an infrastructure view of the network and a service
view of the network.
9 . A computer program product wherein computer instructions, when
processed by a computer, adapt the operation of the computer to perform a
method for managing a network comprising a plurality of network elements,
the method comprising:
retrieving, for each of the network elements to be managed within the
network, respective configuration information, status information and
connections information;
determining, using the retrieved information, at least a portion of the
connections by which data is communicated between the network elements to
be managed; and
storing, in a computer readable storage medium, data representing at
least a portion of the retrieved network element information and determined
network element connections.
10 . Apparatus for managing a network comprising a plurality of network
elements, comprising:
means for retrieving, for each of the network elements to be managed
within the network, respective configuration information, status information
and connections information;
means for determining, using the retrieved information, at least a
portion of the connections by which data is communicated between the
network elements to be managed; and
means for storing, in a computer readable storage medium, data
representing at least a portion of the retrieved network element information
and determined network element connections.
| Section | Controller | Decision Date |
|---|---|---|
| # | Name | Date |
|---|---|---|
| 1 | 6560-CHENP-2012 FORM-5 25-07-2012.pdf | 2012-07-25 |
| 1 | 6560-CHENP-2012-Correspondence to notify the Controller [23-09-2022(online)].pdf | 2022-09-23 |
| 2 | 6560-CHENP-2012 FORM-3 25-07-2012.pdf | 2012-07-25 |
| 2 | 6560-CHENP-2012-US(14)-HearingNotice-(HearingDate-28-09-2022).pdf | 2022-09-16 |
| 3 | 6560-CHENP-2012-ABSTRACT [28-03-2019(online)].pdf | 2019-03-28 |
| 3 | 6560-CHENP-2012 FORM-18 25-07-2012.pdf | 2012-07-25 |
| 4 | 6560-CHENP-2012-Annexure [28-03-2019(online)].pdf | 2019-03-28 |
| 4 | 6560-CHENP-2012 FORM-1 25-07-2012.pdf | 2012-07-25 |
| 5 | 6560-CHENP-2012-CLAIMS [28-03-2019(online)].pdf | 2019-03-28 |
| 5 | 6560-CHENP-2012 CLAIMS SIGNATURE LAST PAGE 25-07-2012.pdf | 2012-07-25 |
| 6 | 6560-CHENP-2012-COMPLETE SPECIFICATION [28-03-2019(online)].pdf | 2019-03-28 |
| 6 | 6560-CHENP-2012 CLAIMS 25-07-2012.pdf | 2012-07-25 |
| 7 | 6560-CHENP-2012-DRAWING [28-03-2019(online)].pdf | 2019-03-28 |
| 7 | 6560-CHENP-2012 POWER OF ATTORNEY 25-07-2012.pdf | 2012-07-25 |
| 8 | 6560-CHENP-2012-FER_SER_REPLY [28-03-2019(online)].pdf | 2019-03-28 |
| 8 | 6560-CHENP-2012 PCT PUBLICATION PAGE 25-07-2012.pdf | 2012-07-25 |
| 9 | 6560-CHENP-2012 FORM-2 FIRST PAGE 25-07-2012.pdf | 2012-07-25 |
| 9 | 6560-CHENP-2012-FORM 3 [28-03-2019(online)].pdf | 2019-03-28 |
| 10 | 6560-CHENP-2012 DRAWINGS 25-07-2012.pdf | 2012-07-25 |
| 10 | 6560-CHENP-2012-OTHERS [28-03-2019(online)].pdf | 2019-03-28 |
| 11 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 25-07-2012.pdf | 2012-07-25 |
| 11 | 6560-CHENP-2012-FORM 4(ii) [27-12-2018(online)].pdf | 2018-12-27 |
| 12 | 6560-CHENP-2012 DESCRIPTION(COMPLETE) 25-07-2012.pdf | 2012-07-25 |
| 12 | 6560-CHENP-2012-FER.pdf | 2018-06-28 |
| 13 | 6560-CHENP-2012-FORM 3 [13-06-2018(online)].pdf | 2018-06-13 |
| 13 | 6560-CHENP-2012.pdf | 2012-07-29 |
| 14 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 21-01-2013.pdf | 2013-01-21 |
| 14 | 6560-CHENP-2012-FORM 3 [24-03-2018(online)].pdf | 2018-03-24 |
| 15 | 6560-CHENP-2012 ASSIGNMENT 21-01-2013.pdf | 2013-01-21 |
| 15 | 6560-CHENP-2012-FORM 3 [05-01-2018(online)].pdf | 2018-01-05 |
| 16 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 09-06-2015.pdf | 2015-06-09 |
| 16 | 6560-CHENP-2012 FORM-3 18-06-2013.pdf | 2013-06-18 |
| 17 | 6560-CHENP-2012 FORM-3 09-06-2015.pdf | 2015-06-09 |
| 17 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 18-06-2013.pdf | 2013-06-18 |
| 18 | 6560-CHENP-2012 CORRESPONDENCE OHERS 02-03-2015.pdf | 2015-03-02 |
| 18 | 6560-CHENP-2012 FORM-3 07-10-2013.pdf | 2013-10-07 |
| 19 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 07-10-2013.pdf | 2013-10-07 |
| 19 | 6560-CHENP-2012 FORM-3 02-03-2015.pdf | 2015-03-02 |
| 20 | 6560-CHENP-2012 FORM-3 08-10-2013.pdf | 2013-10-08 |
| 20 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 20-10-2014.pdf | 2014-10-20 |
| 21 | 6560-CHENP-2012 FORM-3 20-10-2014.pdf | 2014-10-20 |
| 21 | abstract6560-CHENP-2012.jpg | 2013-10-09 |
| 22 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 11-08-2014.pdf | 2014-08-11 |
| 22 | 6560-CHENP-2012 FORM-3 05-02-2014.pdf | 2014-02-05 |
| 23 | 6560-CHENP-2012 FORM-3 11-08-2014.pdf | 2014-08-11 |
| 23 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 05-02-2014.pdf | 2014-02-05 |
| 24 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 05-02-2014.pdf | 2014-02-05 |
| 24 | 6560-CHENP-2012 FORM-3 11-08-2014.pdf | 2014-08-11 |
| 25 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 11-08-2014.pdf | 2014-08-11 |
| 25 | 6560-CHENP-2012 FORM-3 05-02-2014.pdf | 2014-02-05 |
| 26 | 6560-CHENP-2012 FORM-3 20-10-2014.pdf | 2014-10-20 |
| 26 | abstract6560-CHENP-2012.jpg | 2013-10-09 |
| 27 | 6560-CHENP-2012 FORM-3 08-10-2013.pdf | 2013-10-08 |
| 27 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 20-10-2014.pdf | 2014-10-20 |
| 28 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 07-10-2013.pdf | 2013-10-07 |
| 28 | 6560-CHENP-2012 FORM-3 02-03-2015.pdf | 2015-03-02 |
| 29 | 6560-CHENP-2012 CORRESPONDENCE OHERS 02-03-2015.pdf | 2015-03-02 |
| 29 | 6560-CHENP-2012 FORM-3 07-10-2013.pdf | 2013-10-07 |
| 30 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 18-06-2013.pdf | 2013-06-18 |
| 30 | 6560-CHENP-2012 FORM-3 09-06-2015.pdf | 2015-06-09 |
| 31 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 09-06-2015.pdf | 2015-06-09 |
| 31 | 6560-CHENP-2012 FORM-3 18-06-2013.pdf | 2013-06-18 |
| 32 | 6560-CHENP-2012 ASSIGNMENT 21-01-2013.pdf | 2013-01-21 |
| 32 | 6560-CHENP-2012-FORM 3 [05-01-2018(online)].pdf | 2018-01-05 |
| 33 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 21-01-2013.pdf | 2013-01-21 |
| 33 | 6560-CHENP-2012-FORM 3 [24-03-2018(online)].pdf | 2018-03-24 |
| 34 | 6560-CHENP-2012-FORM 3 [13-06-2018(online)].pdf | 2018-06-13 |
| 34 | 6560-CHENP-2012.pdf | 2012-07-29 |
| 35 | 6560-CHENP-2012 DESCRIPTION(COMPLETE) 25-07-2012.pdf | 2012-07-25 |
| 35 | 6560-CHENP-2012-FER.pdf | 2018-06-28 |
| 36 | 6560-CHENP-2012-FORM 4(ii) [27-12-2018(online)].pdf | 2018-12-27 |
| 36 | 6560-CHENP-2012 CORRESPONDENCE OTHERS 25-07-2012.pdf | 2012-07-25 |
| 37 | 6560-CHENP-2012 DRAWINGS 25-07-2012.pdf | 2012-07-25 |
| 37 | 6560-CHENP-2012-OTHERS [28-03-2019(online)].pdf | 2019-03-28 |
| 38 | 6560-CHENP-2012 FORM-2 FIRST PAGE 25-07-2012.pdf | 2012-07-25 |
| 38 | 6560-CHENP-2012-FORM 3 [28-03-2019(online)].pdf | 2019-03-28 |
| 39 | 6560-CHENP-2012 PCT PUBLICATION PAGE 25-07-2012.pdf | 2012-07-25 |
| 39 | 6560-CHENP-2012-FER_SER_REPLY [28-03-2019(online)].pdf | 2019-03-28 |
| 40 | 6560-CHENP-2012 POWER OF ATTORNEY 25-07-2012.pdf | 2012-07-25 |
| 40 | 6560-CHENP-2012-DRAWING [28-03-2019(online)].pdf | 2019-03-28 |
| 41 | 6560-CHENP-2012 CLAIMS 25-07-2012.pdf | 2012-07-25 |
| 41 | 6560-CHENP-2012-COMPLETE SPECIFICATION [28-03-2019(online)].pdf | 2019-03-28 |
| 42 | 6560-CHENP-2012-CLAIMS [28-03-2019(online)].pdf | 2019-03-28 |
| 42 | 6560-CHENP-2012 CLAIMS SIGNATURE LAST PAGE 25-07-2012.pdf | 2012-07-25 |
| 43 | 6560-CHENP-2012-Annexure [28-03-2019(online)].pdf | 2019-03-28 |
| 43 | 6560-CHENP-2012 FORM-1 25-07-2012.pdf | 2012-07-25 |
| 44 | 6560-CHENP-2012-ABSTRACT [28-03-2019(online)].pdf | 2019-03-28 |
| 44 | 6560-CHENP-2012 FORM-18 25-07-2012.pdf | 2012-07-25 |
| 45 | 6560-CHENP-2012-US(14)-HearingNotice-(HearingDate-28-09-2022).pdf | 2022-09-16 |
| 45 | 6560-CHENP-2012 FORM-3 25-07-2012.pdf | 2012-07-25 |
| 46 | 6560-CHENP-2012-Correspondence to notify the Controller [23-09-2022(online)].pdf | 2022-09-23 |
| 46 | 6560-CHENP-2012 FORM-5 25-07-2012.pdf | 2012-07-25 |
| 1 | search_strat_14-06-2018.pdf |