Author Archives: Ryan

An OSS Security Summary

Posted on by
Reply

Our OSS / BSS manage some of the world’s most vital comms infrastructure don’t they? That makes them pretty important assets to protect from cyber-intrusion. Therefore security is a key, but often underestimated, component of any OSS / BSS project.

Let me start by saying I’m no security expert. However, I have worked with quite a few experts tasked with securing my OSS projects and picked up a few ideas along the way. I’ll share a few of those ideas in today’s post.

We look at:

  1. Security Trust Zones / Realms
  2. Restricting Access to OSS / BSS systems and data
  3. OSS / BSS Data Security
  4. Real-time Security Logging / Monitoring
  5. Patch Management
  6. Useful Security Standards

 

1. Security Trust Zones / Realms

For me, security starts with how you segment and segregate your network and related systems. The aim of segmentation / segregation is to restrict malicious access to sensitive data / systems. The diagram below shows a highly simplified three-realm design, starting at the bottom:

  1. The operator’s Active Network realm – the network that carries live customer traffic and is managed by the CSP / operator [Noting though, that these are possibly managed as virtual and/or leased entities rather than owned]. It comprises the routers, switches, muxes, etc that make up the network. As such, this zone needs to be highly secure. Customers connect to the Active Network at the edge of the organisation’s network, often via CPE (Customer Premises Equipment), NTU (Network Termination Units) or similar. Dedicated Network Operation Centre (NOC) operator terminals tend to connect inside the Active Network
  2. The operator’s Corporate / Enterprise realm – the network that houses the organisation’s corporate IT assets. This is where most corporate staff engage with core business services like desktop tools and so much more. If network operations staff need to connect to the Corporate / Enterprise realm but also reach into the Active Network realm, then an air-gap is usually established by the SCP between the two. This is bridged through technologies like Citrix, RDP (Remote Desktop Protocol) or similar
  3. The Cloud / Internet realm –  the external networks / infrastructure utilised by the organisation that are outside the organisation’s direct control. This includes Internet services, which many corporate users rely on of course. However, it may also include some important components of your OSS/BSS stack if provided as public cloud services, an increasingly common software supply model these days
  4. You’ll also notice the all-important Security Control Points (SCP) like firewalls that provide segregation between the zones

OSS BSS Cloud Security Control Points

In all likelihood, your security trust model will contain more than three zones, but these should be the absolute minimum.

The Active Network should be segregated from the Corporate / Enterprise network so that it can continue to provide service to customers even if the connection between them is lost (or intentionally severed if a security breach is identified).

This is where things get interesting. The Active Network and our Network Management stack rely on Shared Services such as DNS (Domain Naming System), NTP (Network Time Protocol), Identity / Access Management, Anti-Virus and more. These tend to be housed in Corporate / Enterprise realms. If we want the Active Network to be able to operate in complete standalone mode then we need to provide special consideration to the shared services architectures. 

Once we have the security trust zones identified, we now have to determine where our OSS / BSS / management stack resides within the zones. If we use the layers of the TMN Pyramid as a guide:

  • The Network Element Layer (NEL) is the heart of the Active Network
  • The EMS / NMS (Element / Network Management Systems) will also usually reside within the Active Network
  • The OSS / BSS are interesting. They have to interface with the network and EMS / NMS. But they also usually have to interface with corporate systems like data warehouses, reporting tools, etc. They’re so critical to managing the Active Network, they need to be highly secure. That means they could be placed inside the Active Network realm or even have their own special Central Management realm. In other cases, different components of the OSS / BSS might be spread across different realms.

OSS abstract and connect

Note that we also have to consider the systems (eg user portals, asset management systems, etc, etc) that our OSS / BSS need to interface to and where they reside in the trust model.

2. Restricting Access to OSS / BSS systems and data

We want to uniquely control who has access to what systems and data using our OSS / BSS stack.

The Security Trust model also impacts the architectures of Identity Management (Directory Services like Active Directory), User Access Management (UAM) and Privileged Access Management (PAM) solutions and how they control access to our OSS / BSS. 

They serve three purposes:

  • To provide fine-grained management of access to privileged / restricted data and systems within our OSS / BSS
  • To simplify the administrative overhead of managing user access to our OSS / BSS by defining group-based user access policies
  • To log the activities of individual users whilst they use the OSS/BSS and related systems / networks

Most OSS / BSS allow user authentication via Directory Services these days. Most, but not all, also allow roles / privileges to be assigned via Directory Services. For example, RBAC (Role Based Access Control) is policy that is defined by our OSS / BSS applications. It controls what functions users / groups can perform via permission management. For central user administration purposes, it’s ideal that the Directory Service can pass role-based information to our OSS / BSS. 

3. OSS / BSS Data Security

The first step in the data security process is to identify categories of data such as unclassified, confidential, secret, etc.

We then need to consider what security mechanisms need to be applied to each category. There are four main OSS / BSS data security considerations:

  1. Data Anonymisation / Privacy – is the process of removing / redacting / encrypting personally identifiable information from the data sets stored in our OSS / BSS (particularly the latter). Our solutions need to store personal data such as names, addresses, contact details, billing details, etc. We can use techniques to control the pervasiveness of access to that data. For example, we may use a tightly restricted system to store personal details as well as a non-identifiable code (eg LocationID or ServiceID) for use by our other more widely accessed tools (eg PNI / LNI)
  2. Encryption of data at rest – is the process of encrypting the large stores of data used by our OSS / BSS, whether a local database used by each application or in centralised data warehouses
  3. Encryption of data in transit – is the process of encrypting data as it transits between components within your OSS/BSS stack (and possibly beyond). Techniques such as VPNs and IPSec protocols can be used. As we increasingly see OSS / BSS built as web-based applications, we’re using encrypted connections (eg HTTPS, SSL, TLS, etc) to protect our data
  4. Physical security – is the process of restricting physical access to data stores (eg locked cabinets, facilities access management, etc). This isn’t always within our control as an OSS / BSS project team.

 

4. Real-time Security Logging / Monitoring

Ensure all systems in the management stack (OSS, BSS, NMS, EMS, the network, out-of-band management, etc) are logging to a central SIEM (Security Information and Event Management) tool. Oh, and don’t do what I saw one big bank do – they had so many hits occurring just on their IPS / IDS tool that they just left it sitting in the corner unmonitored and in the too-hard basket. By having the tools, they’d ticked their compliance box, but there was no checkbox asking them to actually look at the results or respond to the incidents identified!!

 

5. Patch Management

Software patch management is theoretically one of the simplest security management techniques to implement. It ensures you have the latest, hopefully most secure, version of all software.

OSS / BSS / Management stacks tend to have many, many different components. Not just at the obvious application level, but operating systems, third-party software (eg runtime environments, databases, application servers, message buses, antivirus software, syslog, etc). 

Patch management is often well maintained by IT teams within the Corporate / Enterprise trust zone discussed above. They have access to the Internet to download patches and tools to help push updates out. However, the Active Network zone shouldn’t have direct access to the Internet, so routine patch management could be easily overlooked and/or difficult to implement. Sometimes the software components reside on servers that are rarely logged into and patches can be easily overlooked.

The other problem is that OSS / BSS applications are often heavily customised, making it hard to follow a standard upgrade path. I’ve seen OSS / BSS that haven’t been patched for years, even with something as simple as Jave runtime environments, because it causes the OSS / BSS to fail.

 

6. Useful Security Standards

The following is a list of security standards that I’ve used in the past:

As I mentioned at the start, I’m far from being an expert in the field of network or data security. I’d love to get your feedback if I’m missing anything important!!

The overlaps of DCIM with inventory, asset and config management

Posted on by
Reply

A regular reader of the PAOSS blog recently wrote, “I follow with passion your blog,latest post about Inventory are great [Ed. the reader is talking about this post about LNI and PNI and this one about Inventory vs Asset vs CMDB Management]. I ask you if possible have a post on Inside Plant vs Outside Plant vs Virtual network creation… we usually use CAD based tool for Inside Plant design both for TLC equipment, cabling, cross connection, Distribution Frame, rooms, virtual rooms, rows structure,etc but also for power, conditioning, lighfiring,etc. We also use Network Inventory for Datacenter and server farm modelling.Outside Plant typically deals with GIS tool for cabling infrastructure. And now also virtualizzation of Network is coming with NFV and SDN. What do you think about?”

Great question.

In the post about Inventory vs Asset vs CMDB, we used the following Venn Diagram:

Unfortunately, there’s another circle that’s not shown on this diagram, but should be – the DCIM (Data Centre Infrastructure Management) circle. The overlaps between OSS and DCIM partially answer the questions above. We wrote a 5 part series on DCIM back in 2014 (part one, two, three, four, five), so perhaps it’s time for a re-visit.

The last of those five posts even included another Venn Diagram, as follows:

OSS, DCIM, ITSM Venn Diagram

Data Centre Infrastructure Management (DCIM) shares much of its DNA with OSS, but also has a number of unique differences.

Similarities:

  • IT and network device / inventory management
  • CSPs and Data Centres tend to have many Enterprise customers, and therefore a need to align with their IT service and life-cycle management (ITIL / ITSM) methodologies
  • Electronic data collection and storage to support fulfillment and assurance workflows
  • Analytics and operational decision support
  • Planning and design tools
  • Predictive modelling
  • Process and change management
  • Capacity planning, resource allocation and provisioning

Differences (ie what Data Centres have that traditional CSP networks don’t):

  • Facilities / Building Management Systems (FMS/BMS)
  • Energy / Power management
  • Environment and heat management (HVAC) including management of hot/cold zones
  • Data Centres tend to have less outside plant or inter-site connectivity* (ie most power and network connectivity tends to reside within the Data Centres)
  • However, Data Centre cable management have some slight differences. Network links are more likely to be managed within 3D spatial systems (x, y and height) if at all, rather than the 2D (x and y coordinates) typically plotted by most OSS inventory via GIS (Geographical Information Systems) or CAD (Computer Aided Design) drawings. Data Centre cables tend to be run in spatially-dense above-rack or below-floor trayways. By comparison, cables between sites tends to be less dense and at a fairly consistent height (eg a standard depth underground or a standard height when mounted on towers/poles aboveground)
  • Alternatively, DCs may manage spatial infrastructure through naming conventions such as rooms, rack-rows, racks, rack-position rather than 3D spatial systems
  • Data Centres have traditionally had a higher proportion of virtualised assets than traditional CSPs, although that is now changing with the operator network embracing network virtualisation

 

So let’s now look at how it “might” all hang together (noting that each company is likely to be different depending on their systems and processes):

  • DCIM manages facilities, building, power / PLCs and heating/cooling/HVAC
  • PNI manages physical connectivity (between sites and within the DC) as it can generally manage connectivity to physical ports on patch-panels / frames and physical devices (eg switches and routers) inside the DC. PNI also handles splicing and patching. PNI tools can generally also manage power cabling, although not everyone uses PNI for this
  • LNI (in conjunction with EMS [Element Management Systems] and virtual resource managers) will tend to manage the virtual / logical networks including resource management and orchestration
  • LNI will also tend to provide topological views of the network (often point-to-point links between physical/logical ports rather than the cable routes shown in PNI). LNI may also potentially include rack layouts and other forms of network visualisation. However, LNI tends to only partially show spatial presentation of the data (eg physical locations of “circuit” end-points rather than spatial location of all racks and equipment in 3D)
  • Related compute / storage infrastructure could be managed by DCIM, LNI, VIM, etc
  • And any of this could be cross-referenced as assets in the Asset Management System and/or Configuration Management Database (CMDB)

I can see that CAD might still be required for trayway, HVAC ducting, etc because PNI isn’t really designed with this in mind in 3D. 

Having said that, I’d probably still attempt to get all connectivity and support designed into a spatial visualisation tool like PNI rather than CAD. Afterall, connectivity of any type can be modelled as nodes and arcs (same as PNI). It’s just that ducting tends to have a greater 3D heft than a single line / arc of a typical comms cable. 

Why is it important to have this data in a single spatial system rather than CAD? Well, I figure it should help future augmented reality (AR) use-cases like the ones described in the link.

So here’s the updated diagram:

* There are of course multi-site DC organisations that have links between their sites, but they tend to outsource their long-haul network links to traditional carriers.

The common data store trend

Posted on by
Reply
Some time back, we discussed  A modern twist on OSS architecture that is underpinned by a common data model.
 
Time to discuss this a little more visually.
 
As the blue boxes on the left side of the diagram below show, you may have many different data sources (some master, some slaved). You may have a single OSS tool (monolithic solution) or you may have many OSS tools (best-of-breed approach).
 
You may have multiple BSS, NMS and even direct connections to network devices. You may even have other sources of data that you’ve never used before such as weather patterns, lightning strikes, asset management prediction modelling, SCADA data, HVAC data, building access / security events, etc, etc.
 
The common data model allows you to aggregate those sets to provide insights that have never been readily accessible to you previously.
 
So let’s look at a few key points
  1. Existing network layer systems (eg NMS, NE and their mediation devices) are currently sucking (near)real-time (ie alarm and perf) data out of the network and feeding to an OSS directly. They may also be pushing inventory discovery data to the OSS, although probably only loading less frequently (once-daily typically) .
  2. The common data model provides a few options for data flows: 
    1. If the data store is performant enough, the network layer could feed real-time data to the data store which on-forwards to OSS
    2. multi-home the data from the network to the data store and OSS simultaneously
    3. feed data from the network to the OSS, which may (or not) process before pushing to the data store
  3. Just a quick note regarding data flows: The network will tend to be the master for real-time / assurance flows. However, manual input tends to be the master for design/fulfil flows, so the OSS becomes the master of inventory data as per this link 
  4. The question then becomes where the data enrichment happens (ie appending inventory-related data to alarms) to help with root-cause and service-impact calculations. Enrichment / correlation probably needs to happen in the OSS‘s real-time engine, but it could source enrichment data directly from the network, from the OSS‘s inventory, or from the common data store 
  5. If the modern ETL tools (eg SNMP and syslog collectors, etc) allow you to do your own ETL to a common data store, a vendor OSS would only need one mediation device (ie to take data from the data store), rather than needing separate ones to pull from all the different NMS/EMS/NE) in your network. This has the potential to reduce mediation license costs from your OSS vendor
  6. Having said that, if you have difficult / proprietary interfaces that make it a challenge to do all of your own ETL then it might be best to let your OSS vendor build your mediation / ETL engines
  7. The big benefit of the common data store is you can choose a best-of-breed approach but still have a common data model to build Business Intelligence queries and reports around
  8. The common data store also takes load off the production OSS application / data servers. Queries and reports can be run against the common data platform, freeing up CPU cycles on the OSS for faster user interactions

The Common Data Model is supported by a few key advancements:

  1. In the past, the mediation layer (ie getting data out of the network and into the OSS) was a challenge. Network operators didn’t tend to want to do this themselves. This introduced a dependency on software suppliers / integrators to build mediation devices and sell them to operators as part of their OSS/BSS solutions. But there’s been a proliferation of highly scalable ETL (Extract, Transform, Load) tools in recent years
  2. Many networks used to have proprietary interfaces that required significant expertise to integrate with. The increasing ubiquity of IP networking and common interfaces (eg SNMP and web interfaces like RESTful, JSON, SOAP, XML) to the network layer makes ETL simpler.=
  3. Massively scalable databases that don’t have as much dependency on relational integrity and can ingest data for myriad sources
  4. A proliferation of data visualisation tools that are more user-friendly instead of having to be a coder capable of writing complex SQL queries
 

Softwarisation of 5G

Posted on by
2

As you have undoubtedly noticed, 5G is generating quite a bit of buzz in telco and OSS circles.

For many it’s just an n+1 generation of mobile standards, where n is currently 4 (well, the number of recent introductions into the market mean n is probably now getting closer to 5  🙂  ).

But 5G introduces some fairly big changes from an OSS perspective. As usual with network transformations / innovations, OSS/BSS are key to operationalisation (ie monetising) the tech. This report from TM Forum suggests that more than 60% of revenues from 5G use-cases will be dependent on OSS/BSS transformation.

And this great image from the 5G PPP Architecture Working Group shows how the 5G architecture becomes a lot more software-driven than previous architectures. Interesting how all 5 “software dimensions” are the domain of our OSS/BSS isn’t it? We could replace “5G architecture” with “OSS/BSS” in the diagram below and it wouldn’t feel out of place at all.

So, you may be wondering in what ways 5G will impact our OSS/BSS:

  • Network slicing – being able to carve up the network virtually, to generate network slices that are completely different functionally, means operators will be able to offer tailored, premium service offerings to different clients. This differs from the one-size-fits-all approach being used previously. However, this means that the OSS/BSS complexity gets harder. It’s almost like you need an OSS/BSS stack for each network slice. Unless we can create massive operational efficiencies through automation, the cost to run the network will increase significantly. Definitely a no-no for the execs!!
  • Fibre deeper – since 5G will introduce increased cell density in many locations, and offer high throughput services, we’ll need to push fibre deeper into the network to support all those nano-cells, pico-cells, etc. That means an increased reliance on good outside plant (PNI – Physical Network Inventory) and workforce management (WFM) tools
  • Software defined networks, virtualisation and virtual infrastructure management (VIM) – since the networks become a lot more software-centric, that means there are more layers (and complexity) to manage.
  • Mobile Edge Compute (MEC) and virtualisation – 5G will help to serve use-cases that may need more compute at the edge of the radio network (ie base stations and cell sites). This means more cross-domain orchestration for our OSS/BSS to coordinate
  • And other use-cases where OSS/BSS will contribute including:
    • Multi-tenancy to support new business models
    • Programmability of disparate networks to create a homogenised solution (access, aggregation, core, mobile edge, satellite, IoT, cloud, etc)
    • Self-healing automations
    • Energy efficiency optimisation
    • Monitoring end-user experience
    • Zero-touch administration aspirations
    • Drone survey and augmented reality asset management
    • etc, etc

Fun times ahead for OSS transformations! I just hope we can keep up and allow the operator market to get everything it wants / needs from the possibilities of 5G.

An Asset Management / Inventory trick

Posted on by
Reply

Last week we discussed the nuances between Inventory, Asset and Config Management within an OSS stack. Each one of these tools are designed to supports functionality for different users / persona-groups. However, they also tend to have significant functional overlap. Chances are your organisation doesn’t have separate dedicated tools for each.

So today I’m going to share a trick I’ve used in the past when I’ve only had a PNI (Physical Network Inventory) system to work with, but need to perform asset management style functionality.

Most inventory tools are great at storing the current state of a device that exists in a network. However, they don’t tend to be so great at an asset manager’s primary function – tracking the entire life-cycle of an asset from procurement to decommissioning and sparing / maintenance along the way.

Normally the PNI just records the locations of all the active network equipment – in buildings, exchanges, comms-huts, cabinets, etc. The trick I use is to create an additional location/s for warehouses. They may (or may not) reside in the physical location of your real warehouse/s.

In almost all PNI systems, you have control over the status of the device (eg IN-SERVICE, etc). You can use this functionality to include status of SPARE, UNDER REPAIR, etc and switch a device between active network locations and the warehouse.

These status-change records give you the ability to pin-point the location of a given asset at any point in time. It also gives you trending stats, either as an individual device or as a cohort of devices (eg by make/model).

You can even build processes around it for check-in / check-out of the warehouse and maintenance scheduling.

I should point out that this works if your PNI allows you to uniquely identify a device (eg by make/model + serial number or perhaps a unique naming convention instance). If your PNI device records only show the current function of a device (eg a naming convention like SiteA-Router-0001), then you might lose sight of the device’s trail when it moves through life-cycle states (eg to the warehouse).

The differences between Inventory, Asset and Config Management in an OSS

Posted on by
2

We recently discussed the differences between PNI (Physical Network Inventory) and LNI (Logical Network Inventory) solutions that appear as part of many OSS stacks. 

As promised, today we’ll talk about the subtle differences between:

  • Inventory Management Systems 
  • Asset Management Systems and
  • Configuration Management Databases (CMDB)
  • We might even discuss Virtual Infrastructure (VIM) and Resource Managers as well as Config Managers (different from CMDB) too

Inventory vs Asset vs CMDB

To be honest, the diagram above doesn’t show adequate overlap. Each of these systems has a slightly different purpose, usually for a slightly different set of personas. However, they all play a part in managing the resources that make up an organisation’s Active Network (the network segment dedicated to carrying customer traffic, as opposed to internal corporate traffic).

Let’s start with Inventory Management Systems (IMS) because IMHO, these are the tools that were traditionally responsible for managing service-provider networks. These are the tools typically used by network planners, network engineers, capacity planners and other back-office operational staff.  As mentioned in the link above, these tools can be further broken down into:

  • PNI (Physical Network Inventory) – The physical devices like switches, routers, firewalls as well as the outside plant (OSP) like cables, joints, etc. Generally only used by operators with large, wide-spread networks of physical assets, especially outside plant.
  • LNI (Logical Network Inventory) – The set of objects that are formed using physical infrastructure (and possibly associations to other logical objects). This could include circuits, VLANs, and other overlay network topologies as well as the management of attributes like bandwidth, protocols and other network functionality

These tools tend to focus on the key physical/logical/virtual resources that comprise an operator’s active network (AN). However, they often also support functionality that crosses into other domains such as asset and config management.

Asset Management Systems (AMS), as the name implies, have a more “financial” purpose; where assets are objects of intrinsic financial value to an organisation. AMS tools tend to be used by the accounting and asset management teams. They’re used to track current value (purchase price minus depreciation), warranties, spares management, life-cycles / refresh / end-of-life of assets and their contracts, as well as reactive and predictive maintenance. AMS will tend to store information about most of the Active Network Physical devices. This means they will have records for the same devices as PNI, but often with different information / attributes. They won’t tend to store LNI-related data. However, AMS will often keep information about assets in addition to Active Network devices. This could include software licenses and more.

Configuration Management Databases (CMDB) is more of an IT Service Management (ITSM) terminology. Like many IT concepts, ITSM has been increasingly used in parts of service provider networks. CMDBs are a database of Configuration Items (CIs), where CIs can be logical or physical entities. CIs may (or may not) be physical devices (PNI) or logical resource entities (LNI) and may (or may not) represent tangible values (assets). The main purpose of CIs is to store information about IT services that will allow other ITSM processes, such as Incident, Problem and Change Management, to be performed efficiently.

Not only is there functional overlap between these systems, there’s often also terminology overlap and/or misalignments. Different vendors have different levels of functionality and support alternate use-cases, so the areas of overlap differ between organisations.

Oh, and I also promised to mention VIMs and Config Managers:

Virtual Infrastructure Managers (VIM) are responsible for managing the virtual resources made available by physical infrastructure like compute, storage and network devices. In some cases, VIMs generate virtual network devices (VNFs) or virtual machines (VMs) that could look almost identical to any other device stored in LNI, PNI, AMS and/or CMDB. In fact, instances of these VNFs and VMs may even appear in those systems.

Config Management (as opposed to, but also potentially overlapping with, CMDB), is all about managing the configurations of devices in the network (often active network and corporate network). Each device, such as a router, has a configuration that tells the hardware how to function, where to route traffic, which packets to prioritise, where to send management logs (to the OSS), etc. Being able to monitor and manage these configurations centrally and consistently is the purpose for Config Managers. These are mostly used by network engineers to set policies and golden-configs (ie the config templates that all devices of that type must adhere to consistently). For example, you may have hundreds/thousands of devices in your network and want to re-point all management traffic to a new server as part of an OSS upgrade. Rather than configuring each device separately and manually, you can use the config management tool to push config changes out to the network.

Leave us a message to describe how your organisation use these (and other) tools.

Bleak sentiments

Posted on by
Reply

“People in a tough spot often focus on their own problems, when the answer usually lies in fixing someone else’s.”
Steve Schwarzman.

The telco industry is in a tough spot in many areas around the globe. Sadly, there were more stories of wholesale retrenchments here in Australia this week, including good friends. Revenues falling. Sentiment bleak.

Yet it’s not like most declining industries. Telecom services and remote communications are more in demand than ever before. It’s just that the dynamic has flipped. Previously there was a scarcity mindset around telco services. Now there’s an abundance (in many parts of the world). Connectivity is less of a problem now. Customers have stepped up the hierarchy of needs.

Maybe as industries, telco and OSS, we’re focusing on our own problems? The O in OSS, Operations, can trigger an inward-facing viewpoint (and retrenchments only exacerbate internalisation).

5G isn’t the solution if we’re just looking at it as a new, better model of connectivity. It might be if it can make us better at solving other people’s problems. I suspect OSS will have a big part to play in generating those solutions (or stymieing them!).

Hello Trouble!

Posted on by
Reply

Hello, Trouble.
It’s been a while since we last met.
But I know you’re still out there.
And I have a feeling you’re looking for me.
You wish I’d forget ya.. Don’t ya trouble?
Perhaps it is you, that has forgotten me.
Perhaps I need to come find you.
Remind you, who I am.

Sounds like an apt mindset for working in the OSS industry doesn’t it?

 

Or for marketing knives.

I’ll be honest. I like the OSS perspective better!

 

OSS discovers a network

Posted on by
2

Following yesterday’s post about OSS Inventory, I received another great follow-up question from another avid reader of the PAOSS blog:

“Interesting thoughts Ryan! In addition to ‘faults up’, perhaps there is a case also (obvious?) for ‘discovery up’ to capture ongoing non-planned changes? Wondering have you come across any sort of reconciliation / adaptive inventory patterns like this? Workflow based? Autonomous? (Going to far into chaos theory territory ?“

Yes, we did exactly that with the same tool discussed yesterday that I used back in 2000. In fact, a very clever dev and I got that company’s first-ever auto-discovery tool working on site (using a product supplied by head-office). Discovering the nodals (ie equipment, cards, ports) was fairly easy. Discovering the connectivity within a domain (we started with SDH) was tricky, but achievable. Auto-discovering cross-domain connectivity (ie DSL circuits through physical, SDH transit, ATM and logical connectivity onto the IP cloud) was much trickier as we needed to find/make linking keys across different data sources.

It was definitely workflow based with a routine-driven back-end. We didn’t just want anything that was discovered to be automatically stuffed into (or removed from) the database (think flapping ports or equipment going down temporarily). It could’ve been automous, but we introduced a manual step to approve any of the discoveries made by each automated discovery iteration.

As you know, modern networks / EMS / VIM (resource managers) are much more discoverable. They need to be for modern orchestration and resilience techniques. I don’t think it would be quite so tricky to stitch circuits together as we’re no longer so circuit-oriented as back in 2000.

However, I’d be fascinated to hear from other readers how much of a problem they have trying to marry up different data sources for discovery purposes. I’d also love to hear whether they’re using fully autonomous discovery or using the manual intervention step for the same reason we were. I imagine most are automating, because orchestration plans just need to make use of whatever resources are being presented by the underlying resource managers in near-real-time.

PS. For those wondering what “discovery” is, it’s shown in the lower grey arrow in this diagram from “Orders down, Faults up“

Discovery is the process that allows data to be passed from NMS/EMS/NEs (ie the network or resource managers) directly into the inventory management database. It should be a more reliable and expedient way of sychronising the inventory with the live network. 

The reason for the upper grey arrow is because not all networks have APIs that can be “discovered.” Passive equipment like cable joints and patch-panels don’t have programmatic interfaces. Therefore we need to find other ways to get that data into the Inventory Manager.

Various forms of OSS Inventory

Posted on by
2

After reading other recent posts such as “Orders Down, Faults Up” and “How is OSS/BSS service and resource availability supposed to work?” an avid reader of the PAOSS blog posed the following brilliant question:

“Do you have any thoughts on geospatial vs non geospatial network inventory systems? How often do you see physical plant mapping in a separate system from network inventory, with linkages or integrations between them, vs how often do you see physical and logical inventory being captured primarily in a geospatially oriented system?“

Boy do I ever have some thoughts on this topic!! I’m sure you do too, so I’d love to hear what you think in the comments section below.

I was lucky. The first OSS/BSS that I worked on (all the way back in 2000), had both geo and non-geo (topology) views. It also had a brilliantly flexible data model that accommodated physical and logical inventory. All tightly integrated into one package. There aren’t many tools that can do all of that even today. Like I said, I was lucky to have this as a starting point!!

Like all things OSS/BSS, it starts with the personas and the key tasks they need to perform. Or from the supplier’s perspective, which customer personas they’re most actively targeting.

For example, if you have a significant Outside Plant (OSP) Network, then geo-positioning is vital. The exchanges and comms huts are easy enough to find, but pits, cable routes, easements, etc are often harder to find. It’s not uncommon for a field tech to waste time searching for a pit that’s covered in dirt, grass or snow. And knowing the exact cable route in geo view is helpful for sending field techs to the exact location of a fault (ie helping them to pinpoint the location of the bright yellow excavator that has just sliced through your inter-capital link). Geo-view is also important for OSP designers and the field workforce that builds the OSP network.

But other personas don’t care about seeing the detailed cable route. They just want to see a point-to-point topological link to represent physical connections between the ports on adjacent devices. This helps them to quickly understand the network or circuit / service view. They may also like to see an alarm overlay on the topology to quickly determine which parts of the network aren’t performing as expected. For these personas, seeing all the geo-detail just acts as visual noise that they need to subconsciously filter out to understand the topology view.

These personas also tend to want topological views of the network, not just the physical but the logical and virtual network / service overlays too.

In most cases that I can think of, the physical / OSP inventory tools show the physical devices (ports even) that the OSP network connects into. Their main focus is on the cables, joints, pits, pipes, catenaries, poles, lead-ins, patch-panels, patch-leads, splitters, etc. But showing the termination of cables onto active equipment (Inside Plant or ISP) is an important linking key between the physical and logical views.

The physical port (on the physical device) becomes the key demarcation between physical and logical worlds. The physical port connects physical cables / leads, but it also acts as the anchor point from which to create logical ports to which logical connections are made. As a result, the physical device and port tend to be shown in both physical (geo) and logical inventory tools. They also tend to be shown in both physical and logical network topology views.

In the case of the original OSS/BSS I worked on, it had separate visualisation tools for geo, network and circuit/service, but all underpinned by a common data model.

What’s the best way? Different personas will have different perspectives of course. I prefer for physical and logical inventories to be integrated out of the box (to allow simple cross-ref visually and in queries)…. but I also prefer for them to have different views (eg geo, topology, network, circuit/service) to suit different situations.

I also find it helpful if each of those views allow the ability to drill down deeper into specific sections of the graph if necessary. I’d prefer not to have all of those different views overlaid onto a geo visualisation. Too much visual clutter IMHO, but others may love it that way.

Oh, and having separate LNI (Logical Network Inventory) and PNI (Physical Network Inventory) can be a tricky thing to reconcile. The LNI will almost always have programmatic interfaces (APIs) to collect data from, but will generally have to amalgamate many different sources. Meanwhile, the PNI consists of mostly passive equipment and therefore has no API to collect latest info from. I tend to use strategies at the above-mentioned demarcation point (ie physical ports) to help establish linking keys between LNI and PNI.

BTW. There’s one aspect of the question, “How often do you see physical plant mapping in a separate system from network inventory” that I haven’t fully answered. I’ll cover the question of asset management vs inventory management vs CMDB (Configuration Management Database) in more detail in an upcoming post. [Ed. See link here]

In need of an OSS transformation translator

Posted on by
Reply

As OSS Architects, we have an array of elegant frameworks to call upon when designing our transformational journeys – from current state to a target state architecture.

For example, when providing data mapping, we have tools to prepare current and/or target-state data diagrams such as the following:

Source here.

These diagrams are really elegant and powerful for communicating with other data experts and delivery teams. It’s a data expert language.

Data experts are experts of the ETL (Extract, Transform, Load) process, but often have less expertise with the actual meaning and importance of the data sets themselves. For example, a data expert may know there’s a product offerings table, and each has 23 associated attributes (eg bandwidth, SLA class, etc) available. But they may have less understanding of the 245 product types that are housed in the product’s data table, and even less awareness of the meanings of the thousands of product attributes. You need to be a subject matter expert (SME) to understand that detail about the data. In some cases, the SME might be from your client and knows far more tribal knowledge than you.

We often need other SMEs (the products expert in this case) to help us understand what has to happen with the data during transformation. What do we keep, what do we change, what do we discard, etc.

Just one problem – SMEs might not always speak the same language as the data experts.

As elegant as it is, the data relationships diagram above might not be the most intuitive format for product experts to review and comment.

As with many aspects of Architecture and transformation, if we’re to understand, it’s best to communicate in our audience’s language.

In this case, it might be best to show data mappings as overlays on screenshots that the Product owner is familiar with:

  • From
    • Their current GUI
    • Existing sales order forms
    • Current report templates
  • To
    • Their next-generation GUI
    • New order forms
    • Post-Transform report templates

Such an approach might not look elegant to our data expert colleagues. The question is whether it quickly makes enough sense to the SMEs for you to elicit concise responses from them.

The “right” approach is not always the most effective.

I’d love to hear your tips, tricks and recommendations for speaking / listening in the audience’s language.

New functionality added to Blue Book OSS/BSS Vendor Directory

Posted on by
Reply

We’re excited to announce the release of some new functionality on The Blue Book OSS/BSS Vendor Directory (which now hosts nearly 450 different OSS/BSS supplier listings).

We’ve introduced:

  • An Industry News feed

    If you wish to publish news / press-releases on products, contract wins, changes in ownership structure, job advertisements, tradeshow attendance or any other related news, you can click here to create a news item (note that you have to be logged in and be an authorised listing owner – you can find a how-to guide here).
    If tagged to a vendor, these news items also appear in the listing of that vendor.

    If you are an OSS/BSS buyer and wish to publish news about an Expression of Interest (EOI), Request for Proposal (RFP), or similar,  please leave us a note at the Contact Page and we’ll publish your details.

  • Twitter Feed
    Each of the OSS/BSS vendors that have their Twitter handle registered now have their Twitter feed visible within their listing.

We hope that these two new features make it easier for buyers to find up-to-date information about the suppliers they’re most interested in.

We have plenty of additional new functionality under development and data being loaded, so be sure to check back in from time to time.

If you have any additional features that you think we should add, we’d love to hear from you, so please let us know via the Contact Page too.

Orders down, faults up

Posted on by
Reply

As mentioned in a post about Service and Resource Availability last week, I do tend to think of OSS workflows around an “orders down, faults up,” flow direction. And that means customers (services) at the top, network (resources) at the bottom of the (TMN) pyramid.

I also think of inventory (yellow) as the point where Assurance / Faults (blue) and Fulfillment / Orders (purple) collide and enhance, as per the diagram below.

These are highly generic examples, but let’s take a closer look:

Assurance flow (blue) – an alarm or event in the network (NEL/NE layer) pushes up through the stack to the OSS as a fault. The inventory (network / service) helps to enrich the fault with additional information (eg device name, location, connectivity, correlation of this and other faults, etc) to help resolve the fault (either manually by operators or automatically by algorithms). It also helps associate the fault in the network/resource with the customer/s using those resources. This allows notifications to be issued to customers. Note that this simple flow doesn’t reflect examples such as an incident (ie when a customer notices a problem first and calls it in before the OSS has been able to issue a notification).

Fulfillment flow (purple) – a customer places an order (BML/BSS layer or above) and it pushes down through the stack, including changes in the network (NEL/NE layer). Once all the appropriate network changes have been made, the order is ready for use by the customer. Once again, inventory plays an important part, associating customer / service identifiers with suitable resources from the available resource pool. Generally the (customer facing) service orders won’t have the technology-specific details required to actually update the network configurations though. That’s where the inventory often helps to fill in the knowledge gaps and send technology-specific commands down into the network. [See Friday’s post for more information about CFS and RFS definitions and mappings]

Inventory flows (yellow) – an inventory is relevant to assurance and fulfillment flows if the BSS and network / resource layers don’t hold enough information to be fully processed. The enriching information stored by inventory must come from somewhere. Some of it comes from Discovery (usually an automated process of collecting from the network or other sources), or via Manual / Scripted Input (eg physical network designs including patch cables and splicing). Some data (eg splices) just can’t be collected automatically as they relate to passive equipment that has no programmatic interface. This data just has to be created manually.
But arguably the more important inventory data is actually recording the mappings made from customers (services) to network (resources). Inventory solutions  are often where these linking keys / relationships are recorded.

These flows also tend to indicate the direction of data mastery. Whilst the network itself is the source of truth, Fulfillment flows will start at the BSS and customer / service / order data will tend to be mastered there before orders are pushed into the network as provisioning commands. For assurance flows, the network will tend to be the master source of data, but with enrichment along it’s path northbound.

Just keep in mind that there are many exceptions to these examples. Data and processes can flow in many different ways. The diagram above is just useful for helping newcomers to understand some conceptual processes and data models / flows.

Setting a challenge for clever OSS Architects

Posted on by
2

Back in the old days, there was really only one OSS build model – via big milestone/functionality delivery. You followed a waterfall style delivery where you designed the end-solution up-front, then tried to build, test and handover to that design. The business value was delivered at the end of the project (or perhaps major phases along the way). For the large operators, there may have been multiple projects in-flight at any one time, but the value was still only delivered at the end of each project.

Some clients still follow this model, particularly if they outsource build/transformation projects to suppliers. These clients tend to be smaller and have less simultaneous change underway. OSS build/transform projects tend to be occasional for these clients.

But the larger operators now tend to undertake a constant, Agile evolution of their OSS. There are constant transitions, delivery of value at a regular cadence (eg fortnightly sprints). The operating environments (and the constraints associated with them) tend to be in dynamic flow, at an ever increasing speed. There is no project end-state. The OSS simply doesn’t stay in one state for long because change is happening every day (give or take).

For this reason, I find it interesting that Architects tend to design solutions for a particular end-state. This can be a good thing because it stops Agile projects from meandering off track incrementally. 

Unfortunately, this type of traditional solution design doesn’t fully suit modern delivery though. The traditional solution design doesn’t show the many stepping-stones that delivery teams have to implement – the multiple states required to transition from current-state to end-state. I’ve seen delivery teams being unable to determine a workable sequence of stepping stones that allow the designed end-state to be reached.

So, a challenge for the many clever Architects out there – help delivery teams out by designing the stepping stones, not just the ideal end-state. Update your design templates to describe all the intermediate states and the transition steps between them.

Include diagrams, pre-requisites, dependencies, etc as you normally do, but only as bite-sized chunks for easy consumption by delivery teams rather than even more massive documents than today.

After all, those intermediate states are only experienced briefly and then gone. Obsoleted. In fact all OSS delivery states are only transitory, so we may need to re-think our document template models. Pre-build, during-build and post-build documentation requirements are all waiting to be accommodated within a stepping-stone timeline in a new style of design template.

In most cases, it’s a greater skill to navigate an OSS journey rather than simply predict a destination.

I’d love to hear from Architects and Delivery Teams regarding how you’ve overcome this challenge at your organisation! What models do you use?

Differences between CFS and RFS

Posted on by
Reply

Further to yesterday’s post about Service and Resource Availability, I received some questions about how to discern between CFS (Customer Facing Services) and RFS (Resource Facing Services).

I thought the following description, sourced from TM Forum’s GB999 (Service overview sec 1.1.3), might help clarify the differences:

  • “This enables us to model a wide variety of services in a common class hierarchy while differentiating between Services that are obtained as a Product by a Customer versus those that aren’t. As we will see, a CustomerFacingService is one that is obtained as a Product by a Customer. Therefore, the Customer may have specific control over this Service via its associated Product. In contrast, the Customer never knows explicitly which ResourceFacingServices are being used to support a CustomerFacingService. More importantly, the Customer shouldn’t have to know which ResourceFacingServices are being used, since the Customer hasn’t explicitly obtained them.”
  • CFS are associated with resource technology neutral services i.e. they describe general capabilities and have attributes that are general across many technologies e.g. throughput, latency, SLA /loss rate, availability.
  • CFS and RFS typically have different lifecycles, CFS are related to customer and product changes and RFS to technology changes.
  • RFS are associated with resource technology specific services i.e. they have attributes that predominately relate to a specific technology.
  • RFS typically do some of the following:
    1. Map between the native protocols used to expose management of resources e.g. Netconf, YANG, SNMP, etc.
    2. Provide some integrated approach to provisioning and assuring RFS that span multiple technical domains e.g. slices across RAN and Core).
    3. They may be Operator, SP, ISV or Supplier provided.

Further important notes:

  • Composition of subordinate CFSs to support the CFSs exposed by Production capabilities (iterative composition pattern). These subordinate CFSs may be from other Operational Domains both within the same operator or acquired from third party operators as happens with wholesale interconnect.
  • Mapping of CFS to internal Resource Facing Services (RFS) that abstract into services the resource defined by Suppliers’ Technical Domains whose boundaries are defined by technology and supplier choices. This mapping links the boundary decisions of Operational Domains to the Technical Domain boundary decisions of suppliers.
  • RFSs can be atomic or composite to include other RFS (iterative composition pattern). This is a decision taken by the Operations / Integrator composing or creating RFSs based on deployment needs.
  • In a Service Oriented Architecture any exposed services can be consumed by any other service.

How is OSS/BSS service and resource availability supposed to work?

Posted on by
4

The brilliant question above was asked by a contact who is about to embark on a large OSS/BSS transformation.  That’s certainly a challenging question to start the new year with!!

The following was provided for a little more context:

  • We have a manually maintained table for each address where we can store which services are available—ie. DSL up to 5 Mbps or Fiber Data 300 Mbps

  • This manual information has no data-level connection to the actual plant used to serve the address 

  • In a “perfect world”, how does this work?

  • Where is the data stored? Ex: Does a geospatial network inventory store this data, then the BSS requests it as needed?

  • How does a typical OSS tie together physical network and equipment to products and offerings?

  • How is it typically stored? How is it accessed?

  • Sort of related to the address, we have “Facility” records that include things like the Electronics (Card, slot, port, shelf, etc) and some important “hops” along the way 

  • Right now if a tech makes changes to physical plant, we have to manually update our mapping (if the path changes), spreadsheets (if fiber assignment changes) or paper records (if copper pair assignments change).. additionally, we might need to update the Facilities database

  • It doesn’t “use” it’s “awareness” of our plant or network equipment to do anything except during service orders where certain products are tied to provisioning features—ie. callerID billing code being on an order causes a command to be issued to the switch to add that feature.

  • There is no visibility into network status.. how does this normally work?

  • I feel like I’m missing a fundamental reference point because I’ve never seen an actual working example of “Orders down, faults up”, just manually maintained records that sort of single-directionally “integrate” to network devices but only in the context of what was ordered, not in the context of what is available and what the real-time status is.

Wow! Where do we start? Certainly not an easy or obvious question by any means. In fact it’s one of the trickier of all OSS/BSS challenges.

In the old days of OSS/BSS, services tended to be circuit-oriented and there was a direct allocation of logical / physical resources to each customer service. You received an order, you created a “customer circuit” for the order, you reserved suitable / available resources in your inventory to assign to the circuit, then issued work order activities to implement the circuit. When the work order activities were complete, the circuit was ready for service.

The utilised resources in your inventory system/s were tagged with the circuit ID or service ID and therefore not available to other services. This association also allowed Service Impact Analysis (SIA) to be performed. In the background, you had to reconcile the real resources available in the network with what was being shown in your inventory solution. Relationships were traceable down through all layers of the TMN stack (as below). Status of the resources (eg a Network Element had failed) could also be associated to the inventory solution because alarms / events had linking keys to all the devices, cards, ports, logical ports, etc in inventory .

To an extent, it’s still possible to do this for the access/edge of the network. For example, from the Customer Premises Equipment (CPE) / Network Termination Device (NTD) to the telco’s access device (eg DSLAM or similar). But from that point deeper into the core of the telco network, it’s usually a dynamic allocation of resources (eg packet-switched, routed signal paths).

With modern virtualised and packet-switched networks, dynamic allocation makes its harder to directly associate actual resources with customer services at any point in time. See this earlier post for more detail on the diagram below.

Instead, we now just ask the OSS to push orders into the virtualisation cloud and expect the virtualisation managers to ensure reliable availability of resources. We’ve lost visibility inside the cloud.

So this poses the question about whether we even need visibility now. There are three main states to consider:

  1. At Service Initiation – What resources are available to assign to a service? As long as capacity planning is doing its job and keeping the available resource pool full, we just assume there will be sufficient resource and let the virtualisation manager do its thing
  2. After Service is Commissioned – What resources are assigned to the service at the current point in time? If the virtualisation manager and network are doing their highly available, highly resilient thing, then do we want to know?
  3. During an Outage – What services are impacted by resources that are degraded or not available? As operators, we definitely want to know what needs to be fixed and which customers need to be alerted.

So, let’s now get into a more “modern orchestration and abstraction” approach to associating customer services with resources. I’ve seen it done many different ways but let’s use the diagram below as a reference point (you might have to view in expanded form):

CFS RFS orchestration

 Here are a few thoughts that might help:

  • As mentioned by the contact, “orders down, faults up,” is a mindset I tend to start with too. Unfortunately, data flows often have to be custom-designed as they’re constrained by the available systems, organisation structures, data quality improvement models, preferred orchestration model, etc
  • You may have heard of CFS (Customer Facing Service) and RFS (Resource Facing Service) constructs? They’re building blocks that are often used by operators to design product offerings for customers (and then design the IT systems that support them). They’re shown as blue ovals as they’re defined in the Service Catalog (CFS shown as north-facing and RFS as south-facing)
  • CFS are services tied to a product/offering. RFS are services linked with resources
  • To simplify, I think of CFS like a customer order form (ie what fields and options are available for the customer) and RFS being the technical interfaces to the network (eg APIs into the Domain Managers and possibly NMS/EMS/VIM)
  • Examples of CFS might be VPN, Internet Access, Transport, Security, Mobility, Video, etc
    Examples of RFS might be DSL, DOCSIS, BGP (border gateway protocol), DNS, etc
    See conceptual model from Oracle here:
  • Now, let’s think of how to create this model in two halves:
      • One is design-time – that’s where you design the CFS and/or RFS service definitions, as well as designing the orchestration plan (OP) (aka provisioning plan). The OP is the workflow of activities required to activate a CFS type. This could be as simple as one CFS consuming an RFS stub with a few basic parameters mapped (eg CallingID). Others can be very complex flows if there are multiple service variants and additional data that needs to be gathered from East-West systems (eg request for next available patch-port from physical network inventory [PNI]). Some of the orchestration steps might be automated / system-driven, whilst others might be manual work order activities that need to be done by field workforce.
        Note that the “Logging and Test” box at the left is just to test your design-time configurations prior to processing a full run-time order
      • The other is run-time – that’s where the Orchestrator runs the OP to drive instance-by-instance implementation of a service (including consumption of actual resources). That is, an instantiation of one customer order through the orchestration workflow you created during design-time 
  • A CFS can map parameters from one or more RFS (there can even be hierarchical consumption of multiple RFS and CFS in some situations, but that will just confuse the situation)
  • You can also loosely think of CFS as being part of the BSS and RFS as being part of the OSS, with the service orchestration usually being a grey area in the middle
  • Now to the question about where is the data stored:
    • Design-time – CFS building block constructs are generally stored in a BSS or service catalog. Orchestration plans are often also part of modern catalogs, but could also fall within your BSS or OSS depending on your specific stack
    • Run-time (ie for each individual order) – The customer order details (eg speeds, configurations, etc) are generally stored in “the BSS.” The orchestration plan for each order then drives data flows. This is where things get very specific to individual stacks. The OP can request resource availability via east-west systems (eg inventory [LNI or PNI], DNS, address databases, WFM, billing code database, etc, etc, etc) and/or to southbound interfaces (eg NMS/EMS/Infrastructure-Manager APIs) to gather whatever information is required
    • Distributed or Centralised data – There’s no specific place where all data is collected. Some of the systems (eg PNI/LNI) above will have their own data repositories, whilst others will pull from a centralised data store or the network or other infrastructure via NMS/EMS/VIM
    • Data master – in theory the network (eg NMS/EMS/NE) should be the most accurate store of information, hence the best place to get data from (and your best visibility of current state of the network). Unfortunately, the NMS/EMS/NE often won’t have all the info you need to drive the orchestration plan. For example, if you don’t already have a cable to the requesting customer’s address, then the orchestration plan will have to include an action/s for a designer to use PNI/geospatial data to find the nearest infrastructure (eg joint/pedestal) to run a new cable from, then go through all the physical build activities, before sending the required data back to the orchestration plan. Since the physical network (eg cables, joints, etc) almost never has a programmatic interface, it will require manual effort and manual data entry. Alternatively, the NMS/EMS/VIM might not be able to tell us exactly what resource the service is consuming at any point in time
    • For Specific product offerings – There are so many different possibilities here that it’s hard to answer all the possible data flows / models. The orchestration plan within the Business Orchestration (aka Cross-domain Orchestration) layer is responsible for driving flows. It may have to perform service provisioning, network orchestration and infrastructure control. 

This is far less concise than I hoped. 

If you have a simpler way of answering the question and/or can point us to a better description, we’d love to hear from you!

Developing an OSS Training Plan

Posted on by
Reply

Last year a tier-1 telco asked me to develop a training  / mentoring plan for graduates entering their OSS stream. Not just a short-term training plan, but a 4-5 year career development model for their team. They’re setting aside approximately a day a week for personal development for each trainee entering the program.

That blew me away. I was so impressed that they were willing to invest so much time into the long-term development of their staff.

I’ll share the 5-year OSS Training & Mentoring Plan below, but first a few things that came to mind when preparing it:

  • The key to a successful career is developing rare, enduring and valuable skills as fast as possible, particularly early in their career. Same goes for relationships. These traits have compounding effects in the same way compounding interest works
  • Whilst there was a focus on the individual, it the effort expended also had to contribute intrinsic as well as extrinsic benefits to the telco
  • It had to start with the most basic building blocks and terminologies, both from a global perspective, but also within the telco’s specific context
  • It then had to build from basic into the mastery-level subject matter
  • Learning OSS is not an occasional two-week training course, but an apprenticeship. 
  • Most “real” learning happens through experience in-person, interacting with others (colleagues, clients, sponsors and other stakeholders) and hands-on using tools / data / processes
  • It had to incorporate methods of understanding the telco’s specific context and contributing to it as fast as possible through work-related activities.
  • The reality is that even OSS experts tend to take months before becoming their most productive within a new environment
  • Unlike medicine, there is almost never one “best practice” way to do any OSS tasks
  • It had to look outside the telco’s environment and include interaction with external ideas and expertise through widely attended conferences
  • It had to cover all aspects of OSS from strategy to delivery to operations and all associated roles
  • If certifications can be gained, then all the better
  • Our industry changes quickly, so whilst planning out an indicative syllabus over 5 years, there has to be flexibility to adapt in-flight

Whilst the following OSS Training Plan will be overkill for most, it may help to give you some ideas for creating a factory to build your own Valuable OSS Tripods. 

OSS Training and Mentoring Plan

But OSS is such a broad subject matter to learn and nobody’s learning journey will be the same. I’d love to hear your thoughts about what else should be included in (or omitted from) this OSS Training and Mentoring Plan. Are there any other OSS-related training courses that you’d like to suggest for inclusion?

OSS sell money!

Posted on by
Reply
Huh? But they’re just cost centres aren’t they?
 
Nope, they sell financial outcomes – they reduce downtime, they turn on revenue, they improve productivity by coordinating the workforce, etc…
 
But they only “sell money” if they can help stakeholders clearly see the money! I mean “actually” see it, not “read between the lines” see it! (so many benefits of OSS are intangible, so we have to help make the financial benefits more obvious).
 
They don’t sell network performance metrics or orchestration plans or AI or any other tech chatter. They sell money in the form of turning on customers that pay to use comms services. They sell insurance policies (ie service reliability) that keep customers from churning.
 
Or to think of it another way, could you estimate (in a dollar amount) the consequences of not having the OSS/BSS? What would the cost to your organisation be?

What’s in your OSS for me?

Posted on by
Reply

May I ask you a question?  Do the senior executives at your organisation ever USE your OSS/BSS?

I’d love to hear your answer.

My guess is that few, if any, do. Not directly anyway. They may depend on reports whose data comes from our OSS, but is that all?

Execs are ultimately responsible for signing off large budget allocations (in CAPEX and OPEX) for our OSS. But if they don’t see any tangible benefits, do the execs just see OSS as cost centres? And cost centres tend to become targets for cost reduction right?

Building on last week’s OSS Scoreboard Analogy, the senior execs are the head coaches of the team. They don’t need the transactional data our OSS are brilliant at collating (eg every network device’s health metrics). They need insights at a corporate objective level.

How can we increase the executives’s, “what’s in it for me?” ranking of the OSS/BSS we implement? We can start by considering OSS design through the lens of senior executive responsibilities:

  • Strategy / objective development
  • Strategy execution (planning and ongoing management to targets)
  • Clear communication of priorities and goals
  • Optimising productivity
  • Risk management / mitigation
  • Optimising capital allocation
  • Team development

And they are busy, so they need concise, actionable information.

Do we deliver functionality that helps with any of those responsibilities? Rarely!

Could we? Definitely!

Should we? Again, I’d love to hear your thoughts!

 

ETSI Open Source MANO unveils Release SEVEN

Posted on by
Reply

ETSI Open Source MANO unveils Release SEVEN, enables more than 20,000 cloud-native applications for NFV environments!

The ETSI Open Source MANO group is pleased to unveil its latest release, OSM Release SEVEN. This release brings cloud-native applications to NFV deployments, enabling OSM to on-board over 20,000 pre-existing production-ready Kubernetes applications, with no need of any translation or repackaging. OSM release SEVEN allows you to combine within the same Network Service the flexibility of cloud-native applications with the predictability of traditional virtual and physical network functions (VNFs and PNFs) and all the required advanced networking required to build complex end to end telecom services.

“OSM Release SEVEN is at the forefront of Edge and 5G operations technology, deploying and operating containerized network functions on Kubernetes” said Arno Van Huyssteen, Director of Telco Field Engineering at Canonical. “Complete lifecycle management, automated integration and ongoing workload operations make OSM the leading multi-vendor, multi-cloud MANO solution. Canonical is delighted to support OSM in partnership with leading systems integrators.”

In addition, Release SEVEN extends OSM’s SDN framework to support the next generation of SDN solutions providing higher level primitives, increasing the number of available options for supporting I/O-intensive applications. Furthermore, the plugin models for intra and inter-datacenter SDN have been consolidated, and the management, addition and maintenance of SDN plugins significantly simplified.

“We are very excited with the launch of the new release, featuring a brand new integration with Kubernetes and a number of features focused on carrier-grade production environments. Whitestack’s WhiteNFV “Castelldefels” version, based on OSM Release SEVEN, will keep on making real NFV possible, while dramatically simplifying and reducing the cost of the network functions lifecycle” says Joris Vleminckx, COO at Whitestack. “We are very proud to be members and key contributors of this community!”

Release SEVEN also brings major enhancements designed to improve the overall user experience and interoperability choices. This includes an improved workflow for VNF configuration which allows much faster and complex operations, and the support of additional types of infrastructures, such as Azure and VMware’s vCD 10, complementing the previously available choices (OpenStack-based VIMs, VMware VIO, VMware vCD, AWS, Fog05 and OpenVIM).

“OSM SEVEN brings in support for cloud native apps with distributed configuration and monitoring making it truly ready for building software centric enterprise and operator networks in a smarter and faster way” says Ramesh Ramanathan, Principal Architect, CTO Office, TATA Elxsi. “Tata Elxsi is excited to bring in Release SEVEN features to TEOSM and couple it with its OSS/BSS Microservices for building truly next generation 5G networks.“