1. PDD Development Questions
TLEN 5700
Research Methods
Lecture 7
ITP Candidate Capstone Projects
PDD Development Questions
Kevin Gifford
October 11, 2017

2. Capstone Project Milestones Draft PDD to Instructor
Sep 2017
Oct 2017
Nov 2017
Dec 2017
Topic
Presentations
Wed. Sep 13
Teams & advisors set
Wed. Sep 27
Draft PDD to Advisor
Friday, Oct
Draft PDD to Instructor
Fri. Oct
PDD
Wed. Oct
CDD
Wed. Nov 1
PDR
Wed. Nov 15
CDR
Mon/Wed
Dec 11, 13
PDD: 1st draft to advisor; 2nd draft to Instructor; Final draft to instructor
PDD must be signed by the customer (represents common understanding and goals)

3. Project Definition Document

4. Engineering Design (Applied Research) Definition
Engineering Design Process steps
Define the Problem
Do Background Research
Specify Requirements
Brainstorm Solutions
Choose the Best Solution
Develop Prototype
Test and Redesign

5. Project Definition and Customer Interaction
Who precisely is the customer?
Who is the academic advisor?
Who is the industry advisor?
What is the problem or need? What are the projected/anticipated benefits?
What are the customer requirements for the system or product? Can any constraints be identified?
What previous work has been done in this area?
Previous work: literature searches, business and engineering libraries, trade journals, professional society publications (e.g., IEEE, ACM, etc.), industry experts for inputs and guidance, web searches (e.g., ask Google), online tutorials…
What are the (“my”, “our”) project requirements?

6. Project Definition: Organizational Strategy
Questions
Requirements & Constraints
Design
Drivers
Strategies for Success
Organizational
Functional
Administrative
Engineering Design
Budgetary
Related Products
References
Objectives
and/or Levels of Success
Questions
Hardware
Software

7. Capstone Project Milestones: Requirements Generation
The activities involved in requirements engineering vary widely, depending on the type of system being developed and the specific practices of the organization(s) involved. These may include:
Requirements inception or requirements elicitation - Developers and stakeholders meet, the latter are inquired concerning their needs and wants regarding the software product.
Requirements analysis and negotiation - Requirements are identified (including new ones if the development is iterative) and conflicts with stakeholders are solved
Requirements specification - Requirements are documented in a formal artifact called Requirements Specification (RS). Suggestion: Carry the requirements, and any design drivers, in an Annex
Requirements validation - Checking that the documented requirements and models are consistent and meet the needs of the stakeholder.

8. Project Definition: Customer Stated Project Goal (NASA slant)
This project will provide (1) a Space Wireless Communications Testbed for support of NASA wireless network communication research activities; and (2) Identify programmatic next steps and future research activities to best support NASA Explorations and Operations Missions.
The long-term goal is to set up a comprehensive Proximity Wireless Communications testbed facility with broad RF design, modeling, prototyping, and testing capabilities.
The ExWC Testbed must support automated configuration and build the required software management infrastructure to enable rapid deployment, set-up and ASAP field operations for wireless network communications systems
The required Data Center support infrastructure must be built in a completely automated fashion (e.g., build system).
The required wireless network configuration and administrative services must be able automatically built and must include an automated validation functionality that verifies proper network configuration and expected operations.

9. Related information: LTE Cell Tower (Fixed eNB)

10. Related information: Deployable System & Compact System

11. Related information: 4G/LTE Architecture Overview
While only 2 eNodeBs are shown, in practice there are multiple eNodeBs and multiple instances of the EPC elements; and there are many-to-many links between eNodeBs and MMEs, between MMEs and SGWs, and between SGWs and PGWs.
Mobility Management Entity (MME)
Supports user equipment context, identity, authentication, and authorization
Serving Gateway (SGW)
Receives and sends packets between the eNodeB and the core network
Packet Data Network Gateway (PGW)
Connects the EPC with external networks
Home Subscriber Server (HSS)
Database of user-related and subscriber-related information
Interfaces
S1 interface between the E-UTRAN and the EPC
For both control purposes and for user plane data traffic
X2 interface for eNodeBs to interact with each other
Again for both control purposes and for user plane data traffic

12. Related information: Background on vendors, industry
Nokia, Ericsson: LTE System Hardware and Software (and 3rd party associates)
Who are the four big U.S. carriers?
Who are the big carriers in India, EU?
Let’s chat about vendor market strategies…
Who are the major EPC players?

13. Testbed #2 Boulder Testbed Fixed site radio head (eNB)
Deployable System: Mobile
(eNB) and optional core
vEPC
Data Center
software core
vEPC
Boulder Testbed
Fixed site radio head (eNB)
Deployable System: Mobile
(eNB) and optional core
vEPC
Data Center
software core
vEPC

14. Example: Baseline Test Bed Architecture
Network 1 - Fixed
Network 2 - Mobile

15. Requirements & Constraints
The ExWC Testbed shall support automated configuration and build the required software management infrastructure to enable rapid deployment, set-up and ASAP field operations for wireless network communications systems
The required Data Center support infrastructure must be built in a completely automated fashion.
The required wireless network configuration and administrative services must be able automatically built and must include an automated validation functionality that verifies proper network configuration and expected operations.
The system shall demonstrate operations with at least one fixed eNB and one Deployable System: network topology scenarios (resiliency)
The system shall be able to support flexible core hosting at the Data Center and/or with the deployable system (resiliency, redundancy)
The system shall be able to replicate virtual cores on-demand in an automated, containerized manner via orchestrated SDN/NFV build (replicability, reliability)
The system shall be able to easily, in an automated fashion, replicate the entire system for a remotely located testbed facility.
[Strategy] Build testbed infrastructure in phased manner
[Strategy or Requirement?] Need a modern fixed eNB; keep vEPC up to date

16. Requirements & Constraints
Any questions right now – remember your questions will most likely be of value to your peers as well.
Make appointments with the instructor if need assistance in this regard.
Your academic advisors should be able to assist.

17. Design Drivers
Design Driver #1: We are testing the standard and must be vendor agnostic to both hardware (radio) and softwarization (Network Core)
Design Driver #2: Must have Upgrade Path for evolving network core “virtual EPC” (Evolved Packet Core, vEPC)
Design Driver #3: Must be able to replicate the software cores with no licensing cost impacts

18. Back-up Slides

19. Use Cases (engineering) and User Stories (agile methodologies)
A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user storydescribes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.
User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.
_______________________________________________________________________
In software and systems engineering, a use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system to achieve a goal. The actor can be a human or other external system.
Planning Notes 11-Mar-2013:
Discuss SABL Project Plan with Shea and Louis
Coordinate dates for RSA 2FA TIM at HOSC (Shea, Jim, Shankini); cost share this trip with BioServe
Determine timeline on DTN2 Simulator – coordinate HOSC DTN2 G/W testing, test plan, with the HOSC
Will need to plan Automation support for additional BioServe SABL tasks
Have an IDSCam close-out sprint; can transition to SABL early as necessary
HOSC RSA 2FA meeting this week and travel coordination

20. Capstone Project Milestones: Project Definition Document
Project Definition Document (PDD):  The Project Definition Document (PDD) forms the technical foundation for a design project. Its purpose is to clearly define the design problem that will be solved, and to ensure the design team has the requisite resources and capabilities. The design problem definition consists of an articulation of the need being served, specific objectives and levels of success for the design to satisfy this need in the context of the design course, and specific functional requirements the design must provide to satisfy those objectives. Team capabilities and resources are assessed relative to an initial analysis of the critical project elements (“tall poles”) that must be addressed for a successful design solution. This assignment should be approached in the order given, i.e. define the problem and research related work before the specific objectives are identified.
The PDD is developed in cooperation with the project customer, and represents a common understanding of the project focus, functional requirements, scope, and deliverables. Customer approval is due at the time of PDD submission. Deviations from the set of objectives provided here will not be permitted without customer and advisor approval in the form of a revised PDD.
The Projects Advisory Board (PAB) will review the PDD for clarity of purpose and credibility of the critical project elements, together with the corresponding team capabilities and resources. The PAB will issue a judgment of “acceptable” or “not acceptable” for readiness to begin the conceptual design phase, along with specific feedback on weak PDD components. Only teams with an “acceptable” PDD will be permitted to continue with the design process leading toward the Preliminary Design Review (PDR). Others must revise the PDD until an “acceptable” project definition is obtained.