Technology
›
Telecom, Media & Entertainment
›
Network Construction & Modernization
Core Network Engineering
Complex platform, content, and network decisions where revenue, rights, and customer experience intersect.
Example organizations in this space:
Ericsson
Nokia
Cisco
Juniper
This interactive experience is the shipped product itself — the same application code customers run in production, mounted read-only in your browser over a real sample journey. Not a video, not a mockup: because the demo and the product are one codebase, it can never drift from the real thing.
Inside this journey
-
Pre-Sales
Qualify and diagnose before investing in a full evaluation cycle.
-
Qualification
Confirm budget window, decision owners, timeline pressures, and procurement constraints before investing in a full evaluation cycle.
Qualification Questions
Scale and technical acceptance criteria
- To make best use of your time, what peak traffic scale should we validate in the lab (peak concurrent sessions and peak throughput)?
- Which test outcomes will determine whether you want to proceed to a full evaluation?
Interoperability and source systems
- Which access, transport, or OSS/BSS equipment categories or vendor families must the new core interoperate with?
- Do you require testing of nonstandard or proprietary interfaces beyond standard 3GPP profiles?
Procurement, contracting, and compliance constraints
- Are there procurement, security, or regulatory constraints we should know about (data residency, approved supplier lists, localization, certifications)?
- Which commercial model do you expect or prefer for a multi-year core platform?
Budget, decision owners, and timeline
- Is there an allocated budget range to move into a full evaluation (lab and integration testing)?
- Who are the decision owners and signing authorities for a core platform selection? Please list roles or titles.
- What is your target decision window for whether to proceed to a full evaluation, and what is driving that timing?
-
Enterprise Discovery
Map stakeholders, current core architecture, interoperability requirements, performance targets, and success criteria across the buying group.
Discovery Questions
Kickoff: Project Snapshot
- Tell us in a few sentences what triggered your core replacement program and the primary business driver.
- Who is your executive sponsor and which roles must approve the final vendor selection?
- When is your firm, hard deadline for decommissioning the legacy core?
- How many subscribers and peak sessions must your new core support at initial launch?
- Estimate your internal target window for contract signature, in months.
Where the Pressure Is Hottest
- Point to the single outcome from a failed migration that would trigger executive intervention in your organization.
- Describe the most recent production incident tied to your legacy core and its downstream cost.
- Name the supplier or subsystem in your architecture that is currently the most fragile.
- Count the number of customer-impacting incidents in your network in the last 12 months that were caused by core issues.
- Which tolerance threshold on outage minutes would force your team to pause the program?
Who's in the Room (and who blocks progress)
- Highlight the stakeholder group whose objections have derailed similar core decisions in your organization before.
- Map your primary decision path from technical evaluation to contract signature, naming roles at each step.
- Identify the single person or committee in your organization that has veto power over vendor choice.
- Provide your escalation path when an integration issue reaches the C-suite, including roles and expected SLAs.
- At which approval gate in your process would a missed interoperability test be a showstopper?
Integration Friction Points
- Assuming your lab interoperability tests pass, which remaining integration task would still require custom engineering?
- Catalog the external systems that must integrate with your new core, for example OSS/BSS, IMS, policy, and charging.
- Summarize API availability for those systems in your environment, noting whether APIs exist, are documented, or require vendor permission.
- Who currently controls access to your transport and RAN test interfaces and how is access requested?
- If any integration requires vendor-to-vendor engineering that cannot be scheduled within your window, will your team delay the program?
Performance: Targets and Realities
- Point to the top performance metric that, if unmet in production, would cause your customers to churn or expose you to regulatory penalties.
- Provide your target peak throughput, concurrent session capacity, and required headroom percentage at go-live.
- Estimate your expected peak signaling rate during busy hour and the acceptable degradation during scaling events.
- List the monitoring signals and alarms your team requires before accepting automatic scaling changes.
- Name the single performance shortfall that would cause your team to require extended parallel operation beyond your planned window.
Migration Phasing and Responsibilities
- After reviewing typical migration phases, which phase do you expect will be riskiest for your operations, and why?
- Outline your planned phasing for control plane migration, data plane migration, and subscriber cutover.
- Map which internal teams and external vendors are accountable for each migration phase in your plan.
- Count how many parallel environments your team will need for staging, testing, and pre-production validation.
- If the critical staging environment is unavailable for more than two weeks, what fallback decision would your leadership make?
Known Obstacles and Deal Killers
- Highlight the regulatory, contractual, or architectural issue that would make you stop the procurement today.
- Recount any prior supplier transitions your organization ran where costs or timelines exceeded estimates, and what caused the overrun.
- Identify the compliance approvals in your environment that could add more than eight weeks to the timeline.
- List the existing change control gates in your procurement that can pause deployment and the role that triggers each gate.
- At the point where a key integration owner in your organization refuses API access, will you proceed, pause, or terminate the program?
Competitive Landscape and Alternatives
- Assuming price and roadmap were identical, explain why your team would still prefer the incumbent or an internal option.
- Select which alternatives your team is currently evaluating, including the incumbent, an internal rewrite, software-only vendors, or a systems integrator.
- For each alternative you selected, briefly explain its primary advantage in one sentence.
- What conditions would have to hold true for your organization to stay with the current approach rather than change vendors?
- Has anyone on your team proposed building the core in-house, and if so, has a costed plan and timeline been presented?
Operational Readiness and Integration Constraints
- Pinpoint the single operational readiness gap that would prevent a lab-proven core from succeeding in your production environment.
- Catalog the third-party systems your core must integrate with and note whether each exposes a public API, requires adapters, or is unsupported.
- Do you have a dedicated integration engineer or team assigned full time to this project?
- State the percentage of historical call records and telemetry in your possession that is clean, labeled, and available for validation.
- Can your operations and security teams commit to providing access windows, credentials, and test data within your target selection and deployment schedule?
Acceptance Criteria and Next Steps
- After a successful lab and pilot, which single internal approval remains in your process that can still block contract signing?
- Document the objective acceptance criteria your team requires for throughput, session capacity, interoperability, and security before signing.
- Assign an owner and timeline in your organization for running each acceptance test and publishing the results.
- Choose the decision that would accelerate signing immediately after a pilot proves targets, for example immediate PO release, conditional PO, or executive memo.
- Should the pilot meet your criteria, describe any procurement, budget, or governance items in your process that would prevent signing within 30 days.
-
-
Solution Evaluation
Run hands-on lab and integration tests that validate throughput, session capacity, standards compliance, and interoperability against the buyer's acceptance criteria.
- desired_state
- current_state
- stakeholders
- gaps
- success_criteria
- decision_readiness
- desired_state
- decision_readiness
- current_state
- success_criteria
- gaps
- stakeholders
- desired_state
- success_criteria
- stakeholders
- gaps
- current_state
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
- decision_readiness
-
Solution Scope
Define the solution boundary, migration phasing, modules, responsibilities, acceptance criteria, and operational SLAs.
Scope Configuration
- Install COTS Server and Container Platform
- Deploy 5G Core Control Plane CNFs
- Deploy 5G User Plane at Edge Sites
- Configure Network Slicing and Slice Templates
- Migrate Subscriber and Session Data Stores
- Integrate with RAN and Transport Interfaces
- Integrate IMS and Voice Interconnect
- Configure Policy Control and QoS Rules
- Integrate Charging and OSS/BSS Interfaces
- Deploy IP/MPLS Routing Fabric
- Deploy Edge Compute Platform for UPF Hosting
- Perform Live Traffic Cutover and Service Migration
Scope Questions
Install COTS Server and Container Platform
- How many data center sites will host commercial off-the-shelf (COTS) servers for your control and user plane?
- Which server hardware profile will you standardize on (for example CPU cores, memory, NICs, storage type)?
- Who will provision rack power, network cross-connects, and certify grounding at your sites?
- Provide the required Kubernetes cluster size and node resource constraints (CPU, RAM, node count) for your container platform.
- List required compliance certifications for your server and container platform (for example FIPS 140-2, Common Criteria, PCI-DSS if applicable).
Deploy 5G Core Control Plane CNFs
- Describe which 5G control plane network functions you will deploy as containerized network functions (for example AMF Access and Mobility Management Function, SMF Session Management Function, UDM Unified Data Management).
- Specify the expected control-plane signaling rate and maximum concurrent registration attempts per second your network must sustain during peak load.
- Indicate the interfaces and protocols to validate for conformance testing (for example N1 NAS, N2 NGAP, N11 service-based interfaces) and any required 3GPP test suites your team requires.
- Confirm the acceptance criteria for your control plane CNFs including sustained throughput (Gbps), concurrent 5G session capacity, and required 3GPP conformance reports.
- When is your planned handover from lab validation to production CNF deployment scheduled and what freeze window exists for final configuration?
Deploy 5G User Plane at Edge Sites
- Where will your edge User Plane Function (UPF) instances be located (for example central office, regional edge cloud, on-premises enterprise sites) and how many distinct locations are in scope?
- Do your edge sites require local breakout for internet traffic and local DNS or NAT services for hosted applications?
- Is per-site packet capture and telemetry accessible for you to debug UPF performance (for example sFlow, IPFIX, PCAP access)?
- Name the transport encapsulations and tunnels your UPF must support at the edge (for example GTP-U, SRv6, VLAN tagging).
- Estimate the per-edge-site GTP-U tunnel count and peak Gbps throughput you expect in the first 12 months.
Configure Network Slicing and Slice Templates
- State which slice categories you will provision first using slice templates (for example enhanced Mobile Broadband eMBB, ultra-reliable low latency URLLC, massive IoT mMTC).
- Outline the slice-level SLA metrics and isolation thresholds you require (for example one-way latency ms, jitter ms, packet loss %, guaranteed bandwidth Gbps).
- Identify the S-NSSAI (Single Network Slice Selection Assistance Information) or slice identifiers and how you will map them to subscriber segments or enterprise tenants.
- Measure and provide target KPIs per slice such as 95th percentile latency, packet loss, and minimum guaranteed throughput that you will accept.
- Give any regulatory or lawful intercept constraints that affect your slice provisioning and tenant isolation.
Migrate Subscriber and Session Data Stores
- Assign the primary owner for your subscriber data migration tasks and list backup owners for incident handling.
- Set the minimum data migration accuracy threshold (for example 99.995% field-level fidelity) and allowed record reconciliation tolerance you require for acceptance.
- Define which subscriber attributes and session state fields you require to be migrated verbatim (for example IMSI, subscription profile, QoS profiles, PDU session context).
- Enumerate the source data stores you will migrate from (for example legacy HSS/HLR, PCRF logs, billing CDR archives) and their access methods (API, database replication, file export).
- Detail your rollback and dual-write strategies during migration to ensure no subscriber loss and how you will validate sequence numbers and session continuity.
Integrate with RAN and Transport Interfaces
- Report the RAN interface types and versions in your field (for example NG for 5G, S1 for LTE) and any deviations from reference behavior that affect integration.
- Choose which transport technologies are in scope for your core peering (for example IP/MPLS, SRv6, dedicated Ethernet) and indicate any traffic engineering policies required.
- Select the latency and jitter targets between your RAN and UPF that your operator SLA mandates for mobility-sensitive services.
- Authorize who will provide configuration access to your transport equipment and route policies during integration and provide the required contact procedure.
- Calculate the expected number of simultaneous handovers per minute your core must handle during busy-hour mobility events.
Integrate IMS and Voice Interconnect
- How many concurrent voice sessions (SIP dialogs) and emergency call channels must your IMS interconnect support at peak?
- Which SIP interfaces, header manipulations, and emergency routing rules must you implement between the core and session border controllers?
- Who will maintain your numbering plans and E.164 routing tables needed for PSTN interconnect and porting?
- Provide required codec profiles, transcoding points, and whether media anchoring is acceptable for your interconnect calls.
- List regulatory requirements for your IMS voice (for example emergency calling routing, lawful intercept interfaces, number portability) that affect interconnect design.
Configure Policy Control and QoS Rules
- Describe the policy control architecture you need (for example centralized PCRF, service-based policy control, real-time policy push) and the expected control plane calls per second.
- Specify mappings between 5QI identifiers and QoS Class Identifiers you require for prioritized services and the guaranteed bandwidth per class.
- Indicate how dynamic policy triggers will be sourced from your OSS/BSS (for example REST callback, message bus) and the authentication required.
- Confirm how policy rule enforcement mechanisms will be implemented and where your audit logs must be stored (for example centralized logging, SIEM).
- When should policy-to-route translation occur relative to session establishment to meet your service latency targets?
Integrate Charging and OSS/BSS Interfaces
- Where will your online charging be hosted (in-core, dedicated charging cluster, or external cloud) and how is connectivity to billing secured?
- Do you require real-time charging (online) for certain services and batch rating for others?
- Is there an existing mediation layer in your environment and what CDR file formats must be supported for OSS ingestion?
- Name the REST or Diameter endpoints and authentication schemes your billing and OSS/BSS systems expose for integration.
- Estimate expected CDR volume per hour and peak records per second you expect for sizing the mediation pipeline.
Deploy IP/MPLS Routing Fabric
- State the initial number of provider edge (PE) and core routing nodes your deployment requires for the IP/MPLS fabric.
- Outline required MPLS features your network needs (for example segment routing, RSVP-TE, L2/L3 VPN) and whether traffic engineering is required.
- Identify routing scale targets your network must meet for RIB/FIB entries, maximum prefixes, and expected BGP session counts.
- Measure expected control plane churn and route update rates you anticipate during peak reconvergence events.
- Give maintenance window preferences and the maximum acceptable maintenance-induced outage per your site.
Deploy Edge Compute Platform for UPF Hosting
- Assign ownership for your edge compute operations including Kubernetes operator responsibilities and on-call rotation.
- Set the required UPF replica count per site for your high availability needs and the acceptable failover recovery time objective (RTO).
- Define persistent storage requirements your UPF session state needs (for example local SSD, NFS, object store) and backup cadence.
- Enumerate edge networking constraints you face such as MTU limits, VLANs, and local DNS dependencies.
- Detail the monitoring endpoints and metrics you require the edge nodes to emit (for example CPU, packet drop, GTP-U tunnels, session counts).
Perform Live Traffic Cutover and Service Migration
- Report the maximum packet loss, session drop rate, and service restoration time you will accept during cutover for critical services.
- Choose the cutover strategy you prefer for your migration: staged per-slice rollback-capable, blue/green dual-run, or single-window cold cutover.
- Select the primary change window(s) for your migration including timezone, estimated duration, and any blackout periods.
- Authorize the on-call contact list and escalation contacts who can approve an immediate rollback for your migration and provide their contact methods.
- Calculate the required rollback thresholds and automated triggers based on your key monitoring signals (for example >X% session failures or >Y ms control-plane latency).
-
Mutual Commit
Finalize commercial and legal terms, roadmap commitments, delivery milestones, and governance required for a multi-year carrier core selection.
Agreement Modules
- Master Services Agreement (MSA)
- Statement of Work (SOW)
- Order Form & Purchase Agreement
- Software Licensing Agreement
- Service Level Agreement (SLA)
- Support & Maintenance Agreement
- Product Roadmap Commitment
- Program Governance & Change Control Agreement
- Acceptance Test Plan & Acceptance Certificate
- Source Code Escrow Agreement
- Change Order Agreement
- Data Processing Agreement (DPA)
-
Deployment
Operationalize rollout with readiness checks, execution, and outcome validation.
-
Pre-Deployment Readiness
Capture owners, access windows, environments, rollback plans, and cutover sequencing the deployment depends on.
Pre-Deployment Questions
Environment and site access
- Which named environments will the deployment touch? (enter environments as plain names: production, pre-prod, staging, DR — one line per environment)
- Are production and pre-production environments provisioned and reachable for vendor-led tests?
- Is an access method and documented owner assigned for each environment (VPN/bastion/managed jump host)? (so we can plan credential handoffs)
People and ownership
- Who is the primary deployment coordinator (name and role) — the single point of contact for cutover approvals?
- Who owns network/IP change approvals (name and role) required during the cutover? (so we can sequence NOC tasks)
- Are escalation and on-call contacts documented for the cutover weekend?
Data and configuration
- Is the source-of-truth for configuration mappings and subscriber/state data finalized and owned?
- Will live user or session data be migrated during the cutover requiring a freeze window or phased sync? (this defines traffic and validation steps)
Timing, constraints and rollback readiness
- Is there a committed production cutover date/time window? If yes, enter the agreed UTC date/time or write 'TBD'. (we will use this to sequence tasks)
- Has a rollback plan been documented and approved for the cutover, including clear trigger conditions and expected recovery time objective (RTO)?
-
Configuration Details
Lock exact configuration values, integration endpoints, credentials, capacity targets, and monitoring thresholds the deployment team will use.
Configuration Details
Environments & Endpoints
- Enter the production environment name (single token; format: hostname-label, e.g., prod-core; Default: prod-core)
- Enter the production API endpoint URL the deployment will configure (format: https://<host>:<port>/<path> — provide full URL; do NOT include credentials).
- Select the production deployment region (Default: US-East)
Integration & Credentials
- Select the authentication method the seller should configure for northbound API calls (Default: mTLS)
- Enter the OAuth2 client ID or API credential identifier to be configured (identifier only; do NOT paste any secret value).
- Enter the owner of the credential above (format: Full Name — Team). This is the person who will approve secret handoff.
- Enter the name of the secrets manager where the secret will be stored/exchanged (enter product category/name, e.g., your secrets manager). Default: your secrets manager
Integration Endpoints & Protocols
- Enter the buyer's core integration endpoint the seller will point to (format: IP or FQDN:port — e.g., 10.1.1.1:2123 or ngap.example.com:38412).
- Select the transport protocol for core-to-access integration (Default: SCTP)
Capacity, Limits & Monitoring
- Specify the target maximum concurrent sessions to configure for production (numeric; Default: 1000000). Enter digits only.
- Specify the target peak throughput to configure for production (numeric, in Gbps; Default: 200). Enter digits only.
- Select the monitoring transport the deployment should configure for metrics (Default: Prometheus-compatible pull endpoint)
- Enter the monitoring endpoint URL the deployment will send metrics to (format: https://<host>:<port>/ or hostname for Prometheus pull). Leave blank if you selected 'None'.
- Set the CPU utilization alert threshold percentage for system-level P0 alerts (numeric percent; Default: 85). Enter digits only.
-
Deployment
Execute migration and cutover with sequenced tasks, runbooked validations, parallel operation steps, and escalation paths.
-
Go-Live Validation
Formal go/no-go checklist to verify traffic tests, acceptance criteria, monitoring, and rollback readiness before decommissioning legacy infrastructure.
Checklist items
- Obtain written go/no‑go authorization from the buyer's designated approver
- Deliver traffic validation report meeting acceptance criteria
- Deliver interoperability test results and sign-off
- Execute and close cutover dry‑run (dress rehearsal)
- Capture validated rollback point and complete a restore test
- Provision and verify production configuration values and credentials
- Deploy and validate monitoring, alerting, and dashboards
- Distribute operational runbooks and escalation matrix and obtain acknowledgements
- Complete security and compliance acceptance
- Collect per‑site go/no‑go sign-offs and decommission permission
-
-
Success
Confirm operational outcomes, review performance vs success signals, and maintain a shared backlog for issues and enhancement requests.
Success Reviews
- Go-Live Health Check (weeks 1-4)
- First Measurement Review (weeks 4-10)
- Acceptance Gate — Operational Acceptance Decision (around day 90)
- Operational Quarterly Review
- Annual Performance and Stability Review
Issues & Enhancements
- Publish the quarter backlog prioritization and target dates for the top 5 operational fixes.
- Record the formal acceptance decision with the buyer signatory and capture any conditional remediation items and deadlines.
- Confirm the legacy incumbent is either decommissioned or formally retained-read-only with archival completed and fallback habits closed.
- Publish the acceptance decision record including evidence, pass/fail status per criterion, and signatory details.
- Open remediation tickets for any failed or conditional criteria with resolution timelines and verification tests.
- Publish the legacy system wind-down confirmation log showing archive location, contract status, and access restrictions.
- SLA and performance trend review
- Validate that service availability and dropped session rates remain within the tolerances required by the acceptance baselines.
- Agree a prioritized list of operational fixes and enhancement items required to maintain or improve SLA performance.
- Ensure capacity actions are scheduled so throughput and session capacity targets are not at risk next quarter.
- Re-confirm acceptance criteria and owners
- Schedule the capacity scale or tuning window and publish expected impact and rollback plan.
- Update monitoring thresholds and alerting playbooks for dropped-session and control-plane latency events.
- Year-to-date performance summary
- Confirm whether year-one average sustained throughput and session establishment success rate meet the targets recorded in Solution Evaluation.
- Agree a final remediation timeline for any items that remain out of tolerance and a plan for continued monitoring.
- Confirm updates to operational procedures that reduce recurrence of the top incident classes observed in the year.
- Publish the annual performance dossier including all evidence used to compare outcomes to Solution Evaluation targets.
- Create a final remediation schedule for outstanding high-severity items with verification criteria and closure dates.
- Update runbooks and incident response playbooks to reflect agreed procedural changes and distribute to on-call teams.
- All acceptance criteria are read back and ownership for each criterion is confirmed.
- High-priority deployment defects and blockers are captured with remediation tasks and target dates.
- Monitoring and alert thresholds required for early detection are confirmed and enabled.
- Publish the go-live issue register with current severity, description, and target resolution dates.
- Enable or adjust monitoring dashboards to surface session failures and control-plane errors within 24 hours.
- Schedule the first measurement review and circulate required data extracts and access instructions.
- Present first measurement data
- Determine whether control-plane latency and sustained throughput are trending toward targets and document the gap magnitude.
- Agree a prioritized remediation plan with concrete tests and dates to resolve the top 2 metric gaps before the acceptance gate.
- Confirm the data sources and evidence package that will be presented at the acceptance gate meeting.
- Produce a root-cause analysis document for any metric more than 10% off target, including logs and test vectors.
- Schedule and execute the agreed remediation tests in a controlled window and publish results to the shared workspace.
- Assemble the acceptance evidence package referenced in Solution Evaluation and circulate it at least 7 days before the acceptance gate.
- Restate acceptance criteria and numeric targets
- Produce a documented pass/fail decision for each numeric acceptance criterion recorded in Solution Evaluation.
- Deployment validation
- Present outcome data against each criterion
- Root-cause diagnosis for gaps
- Open incident and defect backlog burn-down
- Outstanding remediation and risk inventory
- Backlog health and prioritization
- Enhancement and risk log
- Document pass/fail per criterion
- Agree corrective actions and timelines
- Early adoption and traffic signals
- Operational learnings and monitoring improvements
- Open issues and blockers
- Formal acceptance decision and signatory record
- Confirm acceptance gate readiness
- Capacity and forecast check
- Incumbent system wind-down confirmation
- Agree immediate remediation actions
- Short action item review and closeouts
- Agree remediation commitments and closure timeline