Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 1 of 20
`
`Exhibit 3
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 2 of 20
`
`Keywords: Auto-configuration; Configuration Management; Management
`Automation
`Abstract. In a "managed network" where the location / point of attachment of
`network elements (NE) are entirely planned and the NEs are tightly controlled by an
`element management system, the roll-out of new NEs or changes to the NE HW
`and SW cause considerable overhead. The overhead is due in large part due to the
`concurrent processes at the network operator, NE factory and roll-out field service
`which require extensive interaction. An autoconfiguration method is proposed which
`is able to decouple the individual roll-out processes, i.e., changes in the NE
`configuration and association of NE with certain locations can be changed at any
`time in the roll-out process without incurring additional overhead. This is achieved
`by an autoconfiguration support system under control of the operator where all data
`relevant to a to-be-rolled-out NE is stored. When the NE is booting it can retrieve
`the required configuration and SW which is needed to fulfil the required network
`function at its point of attachment to the network. Finally it is shown that in a
`managed network it is advantageous to use the geo-location of a network element
`as its key identifier in network planning and rollout, rather than a hardware identifier
`as usually employed in DHCP-based autoconfiguration. This is the case because in
`a "managed network" it is important that autoconfiguration support is provided for a
`certain network function at a certain location, rather than autoconfiguration of a
`certain hardware which is attached at an arbitrary location.
`
`1-4244-0799-0/07/$25.00 ©2007 IEEE
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`497
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 3 of 20
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`498
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 4 of 20
`
`Operator benefit:
`planning flexibility until roll-out of ,off-the-shelf" basestations starts
`
`In (Mobile) Telecommunication Networks, new network elements (NEs) such as
`wireless base stations or access points
`are deployed in large numbers
`should be "low cost" in terms of deployed software / hardware and service
`costs
`typically have a rather dynamic roll-out process (i.e., various changes of
`planning and configuration data during roll-out)
`
`The introduction of these NEs into the network causes considerable overhead in
`installation preparation, installation and commissioning:
`extensive data exchange between manufacturer and operator
`manual on-site installation and configuration / commissioning activities
`
`In the future, due to higher complexity and heterogeneity of networks and network
`architectures (2G, 3G, 3G LTE / NGMN, WLAN, WiMAX), and the increasing
`dynamic of configuration (more frequent changes), the simplicity and rapidity of NE
`introduction becomes much more important.
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`499
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 5 of 20
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`500
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 6 of 20
`
`The slide shows an overview of the NE introduction process. The following steps
`have to be performed:
`1. At the factory, every NE has to be equipped with its HW DB.
`2. The operator has to supply that information which goes into the "site"- and
`"project"-specific parts of the DB to the manufacturer. The NE DB has to be
`tailored to the network operator requirements before delivery.
`3. HW installation on site by field service.
`4. Commissioning of the installed HW on site. The O&M communication parameters
`have to be entered by the field service. If additional DB information ("site",
`"project") has changed since NE delivery (last minute changes are rather rule than
`exception, especially if NEs are installed at a location different from the planned
`one), the field service has to verify the up-to-dateness of the pre-installed SW and
`DB and provide and configure the updates. The mapping of a specific hardware
`(NE) to the site (and thus to a specific DB) is done manually on site.
`5. The NE is physically connected to the O&M network.
`6. When the O&M connectivity has been established the (potentially updated) NE
`DB is uploaded to the EMS and added to the configuration management database
`(CM DB).
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`501
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 7 of 20
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`502
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 8 of 20
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`503
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 9 of 20
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`504
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 10 of 20
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`505
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 11 of 20
`
`The functional architecture describes the functional blocks and the relationship and dependencies between
`these functional blocks. The slide shows the functions of the network element (Network Element Functions -
`NEF) and the element management system (Element Management Functions - EMF). Both contain generic
`functions and auto-configuration specific functions: Auto-configuration Support Functions (ASF) at EMS side,
`and Node Auto-configuration Functions (NAF) at NE side.
`
`Network Element Functions:
`*Basic Management Function - Agent (BMF-Agent): allows the NE to be managed online locally and remotely
`by means of basic management instructions (classical OAM agent).
`*Node Auto-configuration Control Function (NACF): controls and co-ordinates the execution of the auto-
`configuration activities pertaining to an NE.
`*Software Configuration Function (SCF): provides on initial NE startup the capability to install and activate the
`proper (Core) software version on the NE.
`*Communication Configuration Function - NE (CCF-NE): ensures that an NE is supplied with the proper
`communication parameters (e.g. IP plus ATM, if necessary), and the configuration of the auto-configuration
`support functions themselves.
`*Data Configuration Function - NE (DCF-NE): provides on initial NE startup the capability to invoke the
`generation of the proper database for the NE, download it to the NE and activate it.
`
`Element Management Functions:
`*Basic Management Function - Manager (BMF-Manager): classical OAM manager
`*Node Configuration Function (NCF): allows to manage validated network configurations including vendor-
`specific parameters, and derive necessary bulk NE database updates or scripts for the BMF-Manager (cf.
`above). This function is already available with classical OAM functions (for configuration management) but
`needs to be enhanced towards auto-configuration functionality
`-Data Repository Function (DRF): stores data configurations pertaining to NEs
`*Software Repository Function (SRF): stores software versions pertaining to NEs
`*Communication Configuration Function - EMS (CCF-EMS): EMS part of CCF (cf. description above)
`*Data Configuration Function - EMS (DCF-EMS): EMS part of DCF (cf. description above)
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`506
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 12 of 20
`
`1.
`
`The proposed solution as far as possible decouples manufacturing, operator and field service
`processes with regard to NE software and configuration data. The slide shows an overview of the
`proposed solution for the NE introduction process. The following steps have to be performed:
`At the factory, each NE is equipped and tested with a default SW and configuration database.
`The operator has to prepare information which goes into the "site"- and "project"-specific parts of
`the EMS CM DB. In case "site"- or "project"-specific information changes prior to NE Boot, the
`EMS CM DB just has to be updated. Part of the "site"-specific information are the O&M
`connectivity parameters (e.g. O&M IP address, ATM settings etc.).
`2. The manufacturer delivers the unique NE hardware identifier to the operator. If an NE with
`hardware different from the planned hardware is finally installed, the NE hardware identifier of the
`new NE has to be adjusted in the corresponding O&M connectivity parameters of the EMS CM
`DB.
`3. When the NE is installed at its target location, the field service only installs the HW according to
`the installation procedure and checks the physical connectivity of the NE components and
`interfaces.
`After physical connection to the O&M network the provisioning of the correct NE SW and
`database (as well as the basic O&M connectivity configuration to enable that provisioning) is
`achieved by means of auto-configuration mechanisms.
`5. When the O&M connectivity has been established the NE DB (incl. HW DB) is uploaded to the
`EMS and added to the EMS CM DB.
`
`4.
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`507
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 13 of 20
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`508
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 14 of 20
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`509
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 15 of 20
`
`1. The network node determines its geographical coordinates, by means of the
`positioning device (in the exceptional case an automated positioning is not
`possible, the position data can also be entered manually by the installer). Note
`that it is sufficient to determine this position once, if the location of the node is
`not changed thereafter.
`2. The network node contacts a configuration server, which contains the planned
`configuration or relevant parts thereof, either by sending a broadcast message
`or a directed one, if the address is already known. This message contains the
`geographical coordinates.
`3. The configuration server matches the geographical coordinates to the planned
`nodes' geographical locations. If a sufficiently good match can be made, the
`server determines the sending node to be the planned node. It may update its
`data with details gained from the message, e.g. to store the hardware
`identification of the new node.
`4. The configuration server returns a response to the network node, containing all
`or parts of the configuration data stored in the network plan for the matching
`planned node. The network node updates its configuration with the data
`received in the response.
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`510
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 16 of 20
`
`This slide shows the NE integration with the geo-location solution. In comparison
`with the NE-identifier-based solution (see slide 12) the step to exchange the NE
`identifier (step 2 in slide 12) can be left out. Thus, the following steps have to be
`performed:
`1. At the factory, each NE is equipped and tested with a default SW and
`configuration database. The operator has to prepare information which goes into
`the "site"- and "project"-specific parts of the EMS CM DB. The operator
`futhermore adds a Location identifier to the "site" information and the
`corresponding O&M connectivity parameters. In case "site"- or "project"-specific
`information changes prior to NE Boot, the EMS CM DB just has to be updated.
`Part of the "site"-specific information are the O&M connectivity parameters (e.g.
`O&M IP address, ATM settings etc.).
`2. When the NE is installed at its target location, the field service only installs the
`HW according to the installation procedure and checks the physical connectivity
`of the NE components and interfaces. The field service furthermore provides the
`site's location information to the NE CM DB by one of the previously described
`methods.
`3. After physical connection to the O&M network the provisioning of the correct NE
`SW and database (as well as the basic O&M connectivity configuration to enable
`that provisioning) is achieved by means of auto-configuration mechanisms.
`4. When the O&M connectivity has been established the NE DB (incl. HW DB) is
`uploaded to the EMS and added to the EMS CM DB.
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`511
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 17 of 20
`
`An important aspect of the auto-configuration solution is its relative independence of the existing / emerging management
`environment and its coexistence with conventional management mechanisms. The solution shifts the complexity of deployment
`away from the field service and manufacturing to the O&M system, resulting in an exchange of OPEX for CAPEX. The OPEX
`savings however are expected to clearly outweigh the CAPEX expenditures when large amounts of NE are handled.
`The following benefits can be summarized:
`NE manufacturer:
`*Without autoconfiguration, each NE is equipped with a SW and configuration that is specific for this entity, with respect to
`operator, SW version, element manager type and version. OPEX savings occur at the HW/SW manufacturing as a generic,
`common SW and configuration is installed and tested (no deployment-specific SW/configuration). Provisioning procedures are
`simplified at the HW/SW manufacturing - hence less error prone - as no project specific information is to be supplied. Ultimately,
`the NE may become an "off-the-shelf' product.
`*Field service activities are simplified and reduced, as the provisioning of the correct NE SW and configuration has become an
`operator task that is enabled by the (pre-) installed NE SW (hence field service OPEX savings occur)
`NE manufacturer and the operator:
`*The procedures regarding SW and configuration data provisioning pertaining to the manufacturer / field service on the one hand,
`and the operator on the other hand are decoupled. The responsibilities are clearly delimited and interactions between them are
`reduced to a minimum: a default SW and database is provided by the Siemens HW/SW manufacturing, the field service engineer
`installs the HW according to the installation procedure and checks the physical connectivity of the NE to the O&M network, the
`operator configures the O&M network and the ASS in order to install the proper basic SW and configuration onto the NE. Clearly,
`this contributes to a better NE provisioning.
`Operator
`*OPEX savings occur as NE SW and configuration deployment becomes an operator internal matter (i.e. a preliminary NE
`configuration does not need to be supplied to or synchronized with the manufacturer)
`The described benefits can already be realized with a "conventional" DHCP solution where the HW identifier is used as a key
`identifier. However, more appropriate in a "managed network" is the usage of geo-coordinates, because no exact planning which
`hardware is to be installed at which location is needed, but only the type of hardware that is required must be known.
`Furthermore, it is not required to manually enter this information during installation. The geo-coordinates of network nodes are
`already included in the planning data, and can be used for this method.
`Especially advantageous is the usage of a portable positioning device, such as a GPS receiver, which needs to be connected
`only during the installation so that the network node may determine its position once and use it thereafter as long as the position
`does not change. The positioning device, which may be too expensive to build into the network node, can be reused in
`subsequent installations.
`Alternatively, equipment that is anyway part of a network node, such as its own air interface, or a wireless module attached to
`serve as a backup communication link, may serve as positioning device. Of course, a mobile phone carried by the installer could
`be used in conjunction with a mobile network positioning method to determine the position of the node.
`The described method is cost-efficient, effective and user-friendly. It allows a complete automatic configuration of network nodes
`while allowing the substitution of arbitrary equivalent hardware equipments.
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`512
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 18 of 20
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`513
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 19 of 20
`
`The determination of the coordinates may also be indirect (previous slide). In this
`case information is transmitted that allows determining the geographic location,
`rather than the coordinates themselves. In this case, additional steps may be
`required.
`The network node contacts a configuration server, which contains the planned
`configuration or relevant parts thereof, either by sending a broadcast message or a
`directed one, if the address is already known. This message contains a key suitable
`for feeding into a geo-positioning method, e.g. one of the positioning methods
`offered by mobile networks themselves, such as triangulation. In the case of using a
`mobile network's positioning capability, the key may be a mobile station international
`subscriber identification number (MSISDN).
`The configuration server feeds the key into the suitable geo-positioning method and
`retrieves the corresponding geo-coordinates.
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`514
`
`

`

`Case 6:20-cv-00272-ADA Document 65-5 Filed 03/14/22 Page 20 of 20
`
`Acknowledgements
`
`Thanks
`We wish to thank Johnny Vrancken and Holger Dittberner for valuable
`contributions to this paper.
`
`References
`R. Droms, Dynamic Host Configuration Protocol, RFC 2131, IETF,
`*
`March 1997.
`| S. Alexander, R. Droms, DHCP options and BOOTP vendor
`extensions, RFC 2132, IETF, March 1997
`| Intel Corporation, Preboot Execution Environment (PXE)
`specification
`
`NetVwor
`
`Elemnidt Auto configuraftion in a Managed NetWOrk
`
`Authorized licensed use limited to: Kirkland & Ellis LLP. Downloaded on February 28,2022 at 20:03:38 UTC from IEEE Xplore. Restrictions apply.
`
`515
`
`