Docstoc

MMD+ Requirements

Document Sample
MMD+ Requirements Powered By Docstoc
					                                   CDG Evolution Team - Operators

                                          Version 1.0, July 8, 2006

           SC-ATE TER Review Version: 0.1 – September 22, 2006




             DRAFT
        Requirements Input
                for
     3GPP2 SC-ATE Ad-Hoc
“Technology Evolution Requirements
              (TER)”




                                                               Version 1.0
                      1        DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
                                                           Table of Contents

1    INTRODUCTION ................................................................................................................................................3

2    GENERAL REQUIREMENTS ..........................................................................................................................3

3    “SERVICES FACTORY” REQUIREMENTS .................................................................................................4

4    DEVICE REQUIREMENTS ..............................................................................................................................5

5    POLICY REQUIREMENTS ..............................................................................................................................7

6    SESSION CONTROL REQUIREMENTS ........................................................................................................9

7    MOBILITY MANAGEMENT AND HANDOFF REQUIREMENTS ............................................................9

8    DATA REPOSITORY REQUIREMENTS ..................................................................................................... 11

9    SECURITY REQUIREMENTS ....................................................................................................................... 11

10     QUALITY OF SERVICE REQUIREMENTS ............................................................................................. 13

11     NAT AND FIREWALL TRAVERSAL REQUIREMENTS ....................................................................... 14

12     PEERING REQUIREMENTS ....................................................................................................................... 14

13     ACCOUNTING AND CHARGING REQUIREMENTS............................................................................. 15

14     REGULATORY REQUIREMENTS............................................................................................................. 16

15     OAM&P REQUIREMENTS.......................................................................................................................... 16

16     INTERCONNECTION TO LEGACY NETWORKS .................................................................................. 17

17     SERVICES REQUIREMENTS ..................................................................................................................... 17

APPENDIX – VOIP FEATURE DESCRIPTIONS ................................................................................................ 20




                                                                                                                                  Version 1.0
                                                                               2                  DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
1 Introduction
To be determined.

2 General Requirements

    Shall = Mandatory
    Should = Optional

  R.001: The network shall enable a highly scalable and manageable architecture.

  R.002: The network shall support reliable network elements (e.g., no single points of failure, fast
  recovery from software and hardware failures, continuous system operation, in-service software and
  hardware upgrades)

  R.003: The network shall provide management of all real-time and non-real-time SIP and non-SIP
  based services hosted and partnered by the NSP to meet customer expectations of service quality in
  home and visited networks subject to provider agreements.

  R.004: The network shall be able to accommodate future radio access network evolution.

  R.005: The network shall provide network elements interconnected through standardized interfaces
  using a minimal set of protocols.

  R.006: The network should minimize protocol translations at signaling and bearer layers to meet
  performance requirements.

  R.007: The network shall provide services platforms for ease of introducing new services.

  R.008: The network shall provide a unified subscriber database using multiple NAIs for all NSP-
  managed SIP and non-SIP services, with partner and BREW services desired but not required.

  R.009: The network shall provide common security framework (layered security) for all SIP/non-SIP
  services and both NSP-hosted/non-NSP hosted services.

  R.010: The network shall provide common mobility framework for all SIP/non-SIP services and both
  NSP-hosted/non-NSP hosted services.

  R.011: The network shall provide common Quality of Service (QoS) framework for all SIP/non-SIP
  services and both NSP-hosted/non-NSP hosted services.

  R.012: The network shall provide unified bearer control and unified signaling control wherever
  operationally feasible and efficient for all SIP/non-SIP services and both NSP-hosted/non-NSP hosted
  services.

  R.013: The network shall support IPv6 as well as inter-working to IPv4/IPv6 devices and
  interconnection to IPv4/IPv6 core and radio networks.

Editor‘s Note: R.013 Rephrased in the SC-ATE meeting as follows (to be used in lieu of R.0177):
     The evolved network shall support IPv6.


                                                                                               Version 1.0
                                                   3           DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
   The evolved network shall support interworking with IPv4/IPv6 terminal devices.
   The evolved network shall support interconnection to IPv4/IPv6 core and radio access networks.
   The evolved network shall support interconnection to other IPv4/IPv6 networks.

 R.014: The network shall support home network operator control of real-time and non-real time
 SIP/non-SIP NSP-hosted and partner services in roaming and non-roaming cases.

 R.015: The network shall support visited network operator having control over bearer resources used
 in the visited network.

 R.016: The network shall support home NSP having control over whether bearer resources are used in
 the visited network as opposed to the home network, when a user is roaming in the visited network.

 R.017: The network shall support diverse devices (e.g. EV-DO Rev A dual band only) with differing
 capabilities (e.g., voice-only, voice and video, data only).

 R.018: The network shall support devices with different applications and features.

 R.019: The network shall allow for integrated and non-integrated devices. Integrated devices have
 EVDO access as well as applications provided by a single device whilst non-integrated devices
 separate them.

 R.020: The network shall allow a user with multiple devices to use those devices at the same time.

 R.021: The network shall provide capability for real-time codec negotiation.

 R.022: The network shall provide capability for transcoding decisions like where to transcode and
 which voice/video codec to use.

 R.023: The network shall provide capability for end-to-end resource reservation and allocation,
 including radio access and core network resources including transport, also addressing resources in
 other NSP networks when SLAs and interconnecting interfaces so allow.

3 “Services Factory” Requirements

 R.024: The network shall support addition of new services with zero impact on existing services.

 R.025: The network shall support the addition, modification, and removal of both SIP-based and non-
 SIP based applications.

 R.026: The network shall support the addition, modification, and removal of new application servers
 without software upgrade of any other components in the network.

 R.027: The network shall support the deployment of new application servers that do not have custom
 integration with billing, provisioning, OAM, or other operational systems.

 R.028: The network shall support different types of programming interfaces on application servers and
 shall support at a minimum Parlay, JAIN SIP, JSLEE, and SIP servlets.


                                                                                              Version 1.0
                                                  4           DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
 R.029: The network shall support both application platforms (SIP and non-SIP application servers in
 which APIs are provided for the development of new applications on the same platform) and
 standalone servers, which provide only a single feature or set of features.

 R.030: The network shall provide a single mechanism for NSP-hosted SIP and non-SIP applications to
 access (read and write) subscriber provisioned data needed by that application.

 R.031: The network shall provide a single mechanism for both SIP and non-SIP applications to be
 notified of changes that are made to subscriber provisioned data needed by that application.

 R.032: The network shall not require software upgrade when new provisioned data are added to the
 repository for a new application.

 R.033: The network shall support subscriber self-provisioning systems (based on web, interactive
 voice response (IVR), or similar mechanisms) to be quickly developed to allow users to manage new
 application data. This implies that the only software development needed should be UI software (the
 web rendering or voice prompts); no new back end development should be required.

 R.034: The network shall support both SIP and non-SIP applications to generate application specific
 accounting information towards the billing mediation systems.

 R.035: The network shall support addition of new applications without any upgrades to the accounting
 and billing systems.

 R.036: It shall be possible for new applications to be added to the network, and for the home operator
 to define feature interaction rules (in the telephony sense) about how these features interact with other
 features, without software upgrade to any components in the network.

 R.037: It shall be possible for new applications to be added to the network, and for the home operator
 to define new rules about how the application interacts with other applications in terms of access to
 network resources, in a uniform way for both SIP and non-SIP applications, without requiring software
 upgrade to any components in the network.

 R.038: The system shall provide the ability to deploy a set of service enablers. These are a set of
 coarse-grained application functions, such as mixers, IVR engines and presence servers, which can be
 accessed by all SIP and non-SIP application servers on the network, and can incorporate information
 from the network.

 R.039: The presence and location service enablers shall incorporate information from various sources
 in the network.

4 Device Requirements

 R.040: The device shall be part of the network in supporting end-to-end security and QoS
 mechanisms.

 R.041: The device shall support network and service enablers offered on the infrastructure side to
 provide MMD+ services, as required.


                                                                                                Version 1.0
                                                   5            DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
R.042: The device shall support either single or multi-mode with multiple air interfaces such as
1xRTT, EVDO, WiFi, 802.16e, WiMax, with LBC (aka phase 2 DOrevC)

R.043: The device shall support feature interaction management of services on the device side prior to
requesting additional services from the network.

R.044: The device shall support bandwidth management as negotiated with the network, provided the
access technology so permits.

R.045: The device shall support QoS management as negotiated with the network.

R.046: The device shall support IPv4 and IPv6.

R.047: The device shall allow both SIP and non-SIP clients to co-exist gracefully.

R.048: The device shall be capable of supporting multiple clients depending on the nature of the
device (single/multi-mode). Examples: BREW client, SIP client(s), clients for non-SIP VZW hosted
services, and clients for 3rd party application service providers.

R.049: The device shall allow for test automation in the NSP test lab and shall provide event logging
and debugging tools/diagnostics within the MMD+ client.

R.050: The device shall support an end-to-end security scheme in concert with the network as
discussed in Section 9 (Security Requirements) of this document.

R.051: The device shall support over the air software updates for client updates and security patches as
well as operating parameters related to access network, analogous to OTASP/OTAPA in 1xRTT
network, which would include exchanging security-related information. Please also see R.0172-173.

R.052: The SIP client shall be supported on one or more of the various device operating systems
(BREW, Linux and Windows).

R.053: The device shall support all identified voice and video codecs. Initial deployments will be
based on EVRC Rev. B codec for voice.

R.054: The device shall support seamless handoff between WiFi and EVDO as well as WiFi and
1xRTT, in both directions. The device shall support all handoffs outlined in Section 7 (Mobility
Management and Handoff Requirements) of this document.

R.055: The device shall work in concert with the network to automatically determine which access
technology (1xRTT, EVDO, WiFi) will be used at any given moment, based on factors such as network
policy (e.g. operator preferred roaming or peering partners), RF conditions, QoS capabilities, and
bandwidth capabilities. In some limited cases, the customer may be allowed to invoke a manual
override (e.g., customer prefers WiFi).

R.056: The device should support an efficient compression scheme for both signaling and transport.

R.057: The device shall support seamless voice hand down from EVDO Rev. A to 1xRTT.



                                                                                              Version 1.0
                                                  6           DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
 R.058: The device shall support the standardized call flows that will be developed for the services
 defined in Section 17 of this document (Voice over IP Requirements).

 R.059: The device shall conform to the NSP User Interface specifications.

 R.060: A hybrid device operating in EVDO Rev. A mode shall support hybrid mode via 3G1x Circuit
 Services Notification rather than by periodically tuning away to 1xRTT.



5 Policy Requirements

 R.061: The network shall provide capabilities to define and enforce the following network level and
 user level policies at various states of device operation (registration, moving, change in access
 technology, and other similar states) based on the following:
      - QoS
      - Security
      - Accounting
      - Mobility
      - Packet Inspection

 R.062: The network shall provide capability for the NSP to make service/resource admission control
 and congestion related decisions for both SIP and non-SIP applications based on the following:

      -   QoS characteristics of the network, including whether or not admission control was achieved
          in the radio access network, whether or not the access network is congested, and similar
          conditions
      -   An indication from the radio access network that a device is no longer available due to loss of
          coverage, power-down, or other similar characteristics
      -   Time of day in relation to application as well as in push services as related to subscriber
      -   The characteristics of the mobile equipment, such as its make, model, software revision,
          screen size, and other similar characteristics
      -   The identity of the subscriber invoking the application, for both SIP and non-SIP applications

 R.063: The network shall provide capability to make policy decisions at the time an application is
 invoked, based on the following:

      -   Other applications that subscriber has simultaneously invoked (including SIP and non-SIP
          applications) based on service characteristics and subscriptions
      -   The media makeup of the application being invoked (audio, video)
      -   The characteristics of the application (real-time, interactive, primary line, etc)

 R.064: The network shall have the capability to change policy decision (like QoS) after an application
 was invoked, at any time after registration based on change in access technology, based on any other
 information like time-of-day, location, application specific behaviors, end-user inputs. The new policy
 decision may result in termination of service, downgrading service (e.g., from video telephony call to
 voice only), and other similar decisions.



                                                                                               Version 1.0
                                                  7            DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
R.065: The network shall provide capability for the NSP to define new characteristics and add new
applications over time, and to define policies based on those characteristics, without software upgrade
to any component of the network.

R.066: The network shall enable the NSP to make decisions at the time an application is invoked, or at
registration time, based on the security posture of the mobile. The security posture includes information
about the operating system versions and patches, anti-virus version, and other similar information.

R.067: The network shall enable the NSP to make decisions about what SIP applications should be
invoked and to guide the behavior of non-SIP applications as a function of network characteristics,
such as roaming states, QoS states in the network, security posture states, and other similar
characteristics.

R.068: The network shall enable the NSP to make decisions for both SIP and non-SIP applications
based on the mobility states of a user, including the identity of their visited network, the geographic
location where they are roaming, the technology of the visited access network (EVDO, 1xRTT, WiFi).

R.069: When roaming, the visited network operator shall be able to make decisions based on the
following:

     -   The types of network resources (QoS, accounting, and so on) available to roaming users
     -   The amount of network resources (percentage of access bandwidth, number of counters, etc.)
         available to roaming users
     -   Whether network resources are granted to a visited subscriber for better than best-effort
         service based on the identity of the home provider
     -   Whether network resources are granted to a visited subscriber based on the application that
         the user is invoking, for both SIP and non-SIP applications
     -   Whether network services or content be delivered to a visiting subscriber based on
         legal/contractual restrictions
     -   Whether composed network applications can be delivered based on local feature interaction
         rules

R.070: Roaming shall not impose any requirements on visited networks such as
     - Upgrade software on any component of their network in order to make a decision to allocate
        resources based on a new application that is being invoked by the roaming subscriber
     - Deploy the same applications (SIP or non-SIP) as the home provider
     - Deploy the same access network technologies as the home provider

R.071: The network shall support peering relationships based on either SLAs between individual NSPs
or NSPs‘ mutual agreements with clearinghouses.

R.072: When the subscriber has multiple active devices, the network shall provide the capability to the
NSP to decide, on an application-by-application basis (for both SIP and non-SIP applications), to
decide whether or not the bearer needs to be brought to the home network.

R.073: The network shall provide capability to make decisions about allocation of network resources
to applications that are provided by 3rd parties.




                                                                                               Version 1.0
                                                  8            DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
6 Session Control Requirements

 R.074: The network shall support basic call/session control.

 R.075: The network shall support users to access services from multiple devices.

 R.076: The network shall control the access to and use of services by subscribers.

 R.077: Contingent upon the visited network‘s ability to support bearer characteristics of a given
 feature or service, the network shall with home network control provide consistent operation of all
 features and services for the roaming user, regardless of

      -   Whether the roaming occurs within the provider‘s network or between provider networks
      -   Whether a particular service is supported in the network roamed to or not
      -   The specific service(s) being invoked

 R.078: The network shall manage the usage of network resources that get applied to SIP-based
 sessions and non-SIP applications, to meet customer expectation of service quality

 R.079: The network shall account for the usage of services, including start and stop times, calling and
 called party identities, and similar features. In roaming cases, both the visited and home networks shall
 support this requirement.

 R.080: Any subscriber profile data required for processing sessions shall be obtained from the single
 shared data repository provided by the system for NSP hosted and partner applications.

 R.081: The network shall provide flexible feature interaction management, handling both static
 interactions (those which can be resolved prior to a call) and dynamic interactions (those which can
 only be resolved during a call) amongst SIP-based features, programmable by the NSP without
 software upgrade of the components in the network. This requirement may apply at both the session-
 control and application layers.

 R.082: The network shall have the capability to determine the set of sessions in progress for a user,
 and to request termination of those sessions.

 R.083: When a user initiates a SIP session, the network shall manage, on a subscriber-by-subscriber
 basis, the set of NSP-managed and partner application servers that get invoked.

7 Mobility Management and Handoff Requirements

 R.084: The network shall provide the following types of handoffs:
         - Layer 2 mechanisms for handoffs within same access technology
         - IP layer mechanisms for handoffs within same access technology, as needed, between
             different access technologies where IP is the common denomination (Based on IPv6
             mechanisms)
         - Application layer mechanisms for handoff of voice services based on different call
             control protocols/models and where there is no common denomination at layer 2 or 3
             (e.g., 1xRTT to WiFi VoIP; 1xRTT to EVDO VoIP; with LBC (aka phase 2 DOrevC)

                                                                                                Version 1.0
                                                   9            DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
R.085: The network shall provide services factory support when roaming which shall enable the
following:
         - NSP to easily define and deploy new services; services should automatically work when
           roaming as well (avoid integration projects with roaming partners when rolling out new
           services)
         - NSP to easily define new services to be completely hosted at the home, while allowing
           some services to use an optimized bearer at the visited network in support of real-time
           service requirements
         - NSP‘s use of service properties and service profile data to enable NSP policy
           enforcement to be defined for specific roamed networks.

R.086: The network shall support access network independence through the support of the following:
        - Various access technologies (EVDO, 1xRTT, WiFi, broadband, LBC (aka phase 2
            DOrevC))
        - Inter-access technology handoff
        - Access-independent authentication for device verification on entry to the NSP network

R.087: The network shall support the following wherever feasible:
        - Fast QoS context transfer
        - Fast security context transfer

R.088: The full suite of policy capabilities shall be possible when roaming, within the limitations of the
capabilities of the visited NSP and bound by the roaming agreements

R.089: The network shall have the ability to decide, on an application-by-application basis, whether
bearer flows for that application are anchored in the home or visited networks. This requirement is
essential for providing visited network anchors for voice, so as to reduce voice latencies to acceptable
levels on par with circuit service, when two roaming users call each other.

R.090: The network shall have the ability to apply load-sensitive policies to services‘ delivery to the
device, with the RAN exposing mechanisms to make available terminal state (e.g., whether the terminal
is ―dormant‖, in order to limit paging load for push service expose).

R.091: The network shall provide the capability for the NSP to control, on an application-by-
application basis, for both SIP and non-SIP applications, whether network-originating packets should,
in absence of an active traffic channel, be delivered via Data-over-Signaling.

R.092: The access network shall provide appropriate triggers to low latency handoffs (similar to the
triggers for EVDO Rev A), such that applications (such as voice) experience service continuity across
various types of handoffs.

R.093: The network shall allow presence and policy functions to obtain device state from the radio
access network (including geographic location, registration status, and other similar information). The
network should also allow these functions to obtain active/dormant status (the assignment of an active
traffic channel to a mobile) through triggered events, according to policies to control the aggregate
event flow (e.g., signaling dormant mobiles after X minutes). This would allow the NSP to make
decisions about how applications should proceed based on such states.

R.094: The network shall support subscribers of the following different types of roaming partners.
                                                                                               Version 1.0
                                                  10           DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
      -    Partners that are full MMD+ networks
      -    Partners that provide only managed and controlled IP services, but do not provide SIP
           services
      -    Partners that do not provide either SIP or managed and controlled IP services, but merely
           provide access
      -    Partners that have wireless access networks of different types, such as EVDO or WiFi, and
           partners with fixed access networks

 R.095: The network shall provide mobility for subscribers that access the network from the public
 Internet, using any available IP access provider, in order the subscriber gets services no matter how
 they are accessed.

8 Data Repository Requirements

 R.096: The network shall provide a general data repository function that is decoupled from other
 functional elements for all SIP and non-SIP applications, services and features including subscriber
 profiles and authorization information.

 R.097: The network shall provide a repository for Layer 2, Layer 3, and application security related
 data.

 R.098: The data repository function shall provide a generic interface for the various SIP and non-SIP
 elements that use the data repository.

 R.099: The network shall provide secure mechanism for trusted partner SIP and non-SIP application
 servers to access the data repository and cached data.

 R.0100: The data repository shall enable easy addition, modification and deletion of fields by NSP to
 support changes in SIP and non-SIP applications, services, and features. It shall be possible to do this
 without requiring interface changes, data repository software upgrades or going through an integration
 project for every service rolled out.

 R.0101: The data repository function must provide a general subscription and notification service,
 which ensures that elements are informed about data changed when they cache data (e.g. policy
 function, SIP service function)

 R.0102: The data repository function shall provide the accounting function by receiving accounting
 events/records.

9 Security Requirements

 R.0103: The network shall provide device security, network security and services security as follows:

          a. Device security shall include features to protect the device from threats, such as virus,
             buffer overflow and malicious code and help prevent the device being used to insert rogue
             packets into the network.

                                                                                               Version 1.0
                                                  11           DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
        b. Network security shall include firewalls, intrusion detection/prevention functions, inter-
           network element security, and security admission control from other domains and the
           Internet
        c. Services security shall include user authentication and authorization, and encryption

R.0104: The network shall provide the following security features:

        - User, device, and network authentication
        - Confidentiality and integrity of signaling and user traffic within NSP network and peered
            networks based on provider agreements
        - Non-repudiation (prevent user deny using network resources, deny sending/receiving traffic)
        - Replay protection
        - Fraud prevention
        - Availability of NSP hosted services and partnered services based on agreements

R.0105: The network shall provide optimized security mechanisms (authentication and encryption) for
Layer 2, Layer 3, and application layer SIP and non-SIP services security. The mechanisms shall
account for impact on device resources (like battery life and number of credentials to be stored in
device) and user experience.

R.0106: The network should minimize authentication exchanges upon attachment to the network.
Single or reduced sign-on is desired across the various network layers, depending on whether the
device is integrated or non-integrated respectively.

R.0107: The network should minimize tunneling and encryption connections when appropriate.

R.0108: The network shall provide a repository for security related data (including identity and
credential management) for Layer 2, Layer 3, and application related security mechanisms.

R.0109: The network shall provide mechanisms for provisioning, caching, and distribution of security
related data like keys.

R.0110: The network shall support mutual authentication between the device and the network.

R.0111: The network shall meet all regulatory security requirements as appropriate.

R.0112: The network shall provide security policy, a set of rules that determines which traffic will and
will not be protected, what kind of protection will be used, how often will rekeying occur, what makes
a device compliant, and similar features.

R.0113: The network shall enable a network-controlled mechanism on the device that provides
security related information to the network. Security posture (status of a device related to OS and
security software updates) of a device is used for admission control to the network. An ‗out of
compliance‘ device shall trigger security events in the network. Please see R.038.

R.0114: In roaming and peering contexts, security policy shall determine which asserted user
identities might be exported by the NSP to the other network.

R.0115: The network shall support security events and incident monitoring of all elements and their
correlation and display to security operations.
                                                                                              Version 1.0
                                                 12           DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
 R.0116: The network shall share security related information with trusted entities (partner SIP and
 non-SIP application servers, and roaming partners) on secure connections.

 R.0117: The network shall provide secure bootstrapping (e.g., GBA) and secure continuous
 management of the mobile devices.

 R.0118: The network shall support the following scenarios for user and device authentication during
 handoffs:
        - Where a ―chain of trust‖ exists between access networks, authentication is deferred until
           after handoff is completed
        - Where no trust exists between access networks, then device and user authentication needs
           to be done prior to handoff

 R.0119: The network shall provide capabilities for logging all security related information including
 flow information for flows that violate security policy and raise a security event; firewall logs and IDS
 information enabling ―live‖ policy compliance monitoring from a Security Operations Center (SOC).

 R.0120: The network shall provide Anomaly detection and mitigation capabilities, performed through
 analysis of the real-time event and flow logging performed by network elements and the device.

10 Quality of Service Requirements

 R.0121: Subscribers should be able to request their QoS preferences (both general and application-
 specific) to the network.

 R.0122: The network shall be able to override the subscriber‘s QoS preferences.

 R.0123: The network shall be able to monitor an individual session‘s QoS.

 R.0124: The network shall provide the ability to authorize end-to-end QoS on a per application and
 per user basis for both SIP and non-SIP applications.

 R.0125: The network shall perform network resource admission control at various enforcement points
 in the airlink and core network.

 R.0126: The network resource admission control decision shall be subject to policy control for both
 SIP and non-SIP applications.

 R.0127: Call Setup latency shall be optimized (reduced) whenever possible for both SIP and non-SIP
 applications (minimize impact of QoS control function).

 R.0128: The network shall provide the capability of rejecting and/or tearing down the application
 setup on failure of the QoS authorization.

 R.0129: The network shall provide the capability for the lower network layers to inform the
 application when QoS resources are lost or changed in either the radio access network.


                                                                                                Version 1.0
                                                   13           DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
 R.0130: The network shall provide the capability for the access network to inform higher network
 layers that a device has disappeared (e.g. due to lost coverage, power-down, and other similar
 conditions)

 R.0131: The network shall provide the capability for the underlying access network changes e.g. due
 to hand-off between differing access network technologies) resulting in a change in QoS provided to be
 shared to the higher network layers.

 R.0132: The network resource admission control shall take into account the airlink QoS reservation,
 the network layer quality of service between the airlink and core network as well as between NSP
 network and external networks as agreed to in the SLAs.

 R.0133: It shall be possible to install, modify, and delete QoS reservations from the AT (user side) as
 well as the network (network side).

11 NAT and Firewall Traversal Requirements

  NAT - Network Address Translation

 R.0134: The network shall work in the presence of NAT devices in NSP networks and partners
 networks.

 R.0135: The network shall operate in the same conditions when firewalls are present, subject to NSP
 defined set of policies.

 R.0136: The network shall not require the frequent and periodic transmission of keepalives over the
 EVDO or 1xRTT network to support NAT traversal. Such keepalives waste valuable air interface
 resources and rapidly drain the battery.

 R.0137: The NAT traversal solutions shall be applicable to SIP and non-SIP applications alike.

 R.0138: The NAT traversal solutions shall not require software upgrade of any components of the
 network when a new application is added.

 R.0139: The NAT traversal solutions shall not require routing of the voice packets back to the home
 network unless fundamentally unavoidable.

 R.0140: The NAT traversal solutions shall not adversely affect the application security

 R.0141: The NAT traversal solutions shall be applicable even in a IPv6 environment

12 Peering Requirements

 R.0142: The network shall support direct and indirect IP peering with other MMD+ and application
 service providers subject to agreed upon SLAs.

 R.0143: The network shall enable NSP to provide policy peering for SIP and non-SIP applications
 with other providers for supporting roamers.

                                                                                              Version 1.0
                                                  14          DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
 R.0144: The network shall support policy peering to allow for both the home and the visited network
 to exert policy control of resources used in the visited network to meet customer expectation of service
 quality.

 R.0145: The network shall not require changes to the policy peering interface to the roaming partner‘s
 network when new services or features are introduced in the home network

 R.0146: The network shall support peering at the SIP level for MMD+ provider partners, and other
 SIP-based provider partners.

 R.0147: The network shall support two types of enterprise peering relationships:

        - The NSP supplies carrier-hosted, application layer services for a device for which the
          enterprise provides access to the NSP‘s network
        - The enterprise provides application layer services for one device in the session and the NSP
          provides such services for another party in the session.

 R.0148: The network shall support SIP peering with the Internet, i.e. calls/requests to and from SIP
 devices in general with special consideration to security and accounting.

 R.0149: The network shall support peering with the PSTN for placing and receiving phone calls.

 R.0150: The network shall provide transcoding when SIP peering with other networks.

 R.0151: The network shall support enforcement of security and privacy functions when SIP peering
 with another network. This applies to incoming as well as outgoing requests.

 R.0152: The network shall support enforcement of network resource policies when SIP peering with
 another network. This applies to incoming as well as outgoing signaling and media.

 R.0153: The network shall support collecting relevant information when SIP peering with other
 network (e.g. accounting, statistics). This applies to incoming as well as outgoing signaling/media and
 to home network and roaming cases.

13 Accounting and Charging Requirements

 R.0154: The network should minimize the number of network elements sending billing records to
 back-end systems. A single point of aggregation should be provided for presentation to the back office.

 R.0155: The network should minimize the number of formats of billing records.

 R.0156: The network shall provide various charging alternatives like charging by bandwidth, by byte,
 by content, by time, by event, by QoS provided.

 R.0157: The network shall support post-paid and pre-paid charging

 R.0158: The network shall enable various accounting triggers (content, byte, application, time) under
 the control of the NSP.

                                                                                               Version 1.0
                                                  15           DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
 R.0159: The network shall provide dynamic charging rules for both SIP and non-SIP applications.

 R.0160: The network shall enable rapid deployment of new hosted applications without requiring the
 hosted applications to generate accounting records on their own.

 R.0161: The network shall enable new applications to be developed and deployed without requiring
 upgrades to back-end billing systems.

14 Regulatory Requirements

 R.0162: The network shall support Lawfully Authorized Electronic Surveillance (LAES) in
 accordance with requirements of CALEA.

 R.0163: The network shall provide a mechanism for a user (including unprogrammed devices, devices
 of non-partner NSPs, and unauthenticated device/client/subscriber) to make emergency (E911) calls.

 R.0164: The network shall properly route calls to emergency service centers based on the location of
 the caller, and convey location information and the identity of the caller.

 R.0165: The network shall provide emergency services for mobile users without requiring manual
 entry of location information.

 R.0166: The network shall leverage visited network support for emergency services in cases where the
 home network is unreachable or unable to provide emergency services.

 R.0167: The network shall support multimedia emergency services, including voice, video and text, at
 the time such interfaces are available from emergency service centers.

 R.0168: It shall be possible for emergency calls to receive QoS or not, and for them to get priority
 over existing calls or not, based on NSP policy.

 R.0169: Emergency services calls shall override calling restrictions which would otherwise prevent a
 user from making a call, such as calling barring or inbound only services.

 R.0170: Emergency services shall be supported across many different types of devices, such as cell-
 phones, dual-mode phones, and softphones.

 R.0171: The network shall support wireless priority service.

15 OAM&P Requirements

 R.0172: The architecture should minimize the number of provisioning points (services databases) in
 the network.

 R.0173: The network shall support Over the Air Service Provisioning (OTASP).

 R.0174: The network shall support Over the Air Parameter Administration (OTAPA).

                                                                                                Version 1.0
                                                 16             DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
 R.0175: The network shall support unified view for easy management/maintenance.

16 Interconnection to Legacy Networks

 R.0176: The network shall provide interconnection to legacy circuit-switched networks. [Disposition:
 Covered in 5.4.3 in the current draft – see SC-ATE-20060911-009.]

 R.0177: The network shall provide interconnection to IPv4 networks. [Disposition: See requirements
 derived from R.013]

 R.0178: The network shall provide interconnection to SIP-based networks.

 R.0179: The network shall provide interconnection to PSTN.

 R.0180: The network shall provide interconnection to other broadband networks.

 R.0181: The network shall provide interconnection to enterprise networks.

17 Services Requirements

 R.0182: The network shall provide the following voice features (based on IP networks and SIP
 protocol).

        -   Call Handoff (CH)
        -   Call Delivery (CD)
        -   Call Forwarding-Busy (CFB)
        -   Call Forwarding Default (CFD)
        -   Call Forwarding-No Answer (CFNA)
        -   Call Forwarding-Unconditional (CFU)
        -   Call Waiting (CW)
        -   Three-Way Calling (3WC)
        -   Calling Number Identification Presentation (CNIP)
        -   Calling Number Identification Restriction (CNIR)
        -   Call Transfer (CT)
        -   Wireless Number Portability (WNP)
        -   Emergency Services-E911
        -   Court Ordered Surveillance/CALEA
        -   Voice Mail Deposit (VMD)
        -   Message Waiting Notification (MWN)
        -   Voice Message Retrieval (VMR)
        -   Ring Back Tones (RBT)
        -   Short Message Service (SMS)
        -   Over the Air Service Provisioning (OTASP)
        -   Over the Air Parameter Administration (OTAPA)
        -   Flexible Alerting (FA)
        -   Abbreviated Dialing (AD)
        -   Outbound Call Restrictions/Dialing Permissions

                                                                                                Version 1.0
                                                  17            DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
        -   Vanity Numbers
        -   Inbound Call restrictions
        -   Directory Assistance (411) with release Link
        -   Feature Code Activation/De-activation
        -   Short Code Dialing
        -   Locally Allowed Abbreviated Dialing
        -   N11 Dialing
        -   Push DTMF to an IVR
        -   Misdialed Calls – Play Proper Network Announcements

ANSI-41 based descriptions are provided in the Appendix; TIA/EIA/IS-664 conformance where
applicable.

R.0183: The network shall exceed the quality of voice service that exists today in the circuit-switched
network architecture in terms of latency and MOS.

R.0184: The network shall provide seamless mobility for Voice service regardless of the access
technology (EVDO, WiFi). Please see Section 16 of this document.

R.0185: The network shall provide local services while roaming (e.g., locally allowed abbreviated
dialing like *POL, *HOPE, *CG).

R.0186: It shall be possible for a particular call to involve both local services and regular applications
that are invoked as part of call processing. For example, originating services like call log generation,
outbound screening, prepaid, and call recording may need to be invoked in conjunction with local
services. It shall be possible to provide feature interaction management in these cases.

R.0187: It shall be possible for the home provider to provide local services, where the local services
are really services that depend on the location context of the caller (e.g. a dial-a-pizza service could be
provided by the home provider, by combining geolocation information about the caller with a google
maps database).

R.0188: When a local service (like dial-a-pizza) is invoked by a subscriber, and it can be provided
either locally or in the home network, the home network policy shall determine which is invoked.

R.0189: It shall be possible to provide ‗alert‘ style local services, where the subscriber receives an
asynchronous message from a local network application when they roam into the local network (e.g.
welcome-sms when a user roams into a foreign country).

R.0190: It shall be possible for the user to dial region-specific dial strings for local services, in
addition to well-known dial strings that invoke a specific local service from every locale. For example,
#TRAFFIC could be defined by NSP to invoke a local traffic readout no matter where it is dialed from.

R.0191: It shall be possible for the invocation of local services to be properly accounted for in the
home network accounting and billing systems.

R.0192: It shall be possible for home network QoS, accounting, security, DPI and mobility policies to
apply to the invocation of local services.



                                                                                                Version 1.0
                                                   18           DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
 R.0193: It shall be possible for the home network provider to allow or disallow the subscriber from
 accessing specific local services.




Appendix a – Partial Abbreviation List

NSP:          Network Service Provider
NAI:          Network Access Identifier
SIP:          Session Initiation Protocol
BREW:         Binary Runtime Environment for Wireless
OAM:          Operations, Administration, and Maintenance
JSLEE:        Java Service Logic Execution Environment
OTASP:        Over-the-air Service Provisioning
OTAPA:        Over-the-air Parameter Administration




                                                                                            Version 1.0
                                                19          DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
Appendix B – VoIP Feature Descriptions

This section provides description of voice features as offered today in ANSI-41 networks.

Call Handoff (CH)
  Call Handoff (CH) provides the ability to transfer wireless calls from one cell site to another as the
  mobile moves through the service area. Handoff may occur between cell sites that use different access
  technologies such as 1xRTT, EVDO Rev. A or WiFi.

Call Delivery (CD)
  Call Delivery (CD) permits a subscriber to receive calls to his or her Directory Number while roaming.

Call Forwarding-Busy (CFB)
  Call Forwarding-Busy (CFB) permits a called subscriber to have the system send incoming calls
  addressed to the called subscriber‘s Directory Number to another Directory Number (forward-to
  number) or to the called subscriber‘s designated voice mailbox, when the subscriber is engaged in a
  call or service.

Call Forwarding Default (CFD)
   Call Forwarding—Default (CFD) permits a called subscriber to send incoming calls addressed to the
   called subscriber‘s Directory Number to the subscriber‘s designated voice mail box or to another
   Directory Number (forward-to number), when the subscriber is engaged in a call, does not respond to
   paging, does not answer the call within a specified period after being alerted or is otherwise
   inaccessible (including no paging response, the subscriber‘s location is not known, the subscriber is
   reported as inactive, Call Delivery not active for a roaming subscriber, Do Not Disturb active, etc.).

Call Forwarding - No Answer (CFNA)
  Call Forwarding—No Answer (CFNA) permits a called subscriber to have the system send incoming
  calls addressed to the called subscriber‘s Directory Number to another Directory Number (forward-to
  number) or to the called subscriber‘s designated voice mail box, when the subscriber fails to answer, or
  is otherwise inaccessible (including no paging response, the subscriber‘s location is not known the
  subscriber is reported as inactive, Call Delivery not active for a roaming subscriber, Do Not Disturb
  active, etc.). CFNA does not apply when the subscriber is considered to be busy.

Call Forwarding - Unconditional (CFU)
  Call Forwarding - Unconditional (CFU) permits a called subscriber to send incoming calls addressed to
  the called subscriber‘s Directory Number to another Directory Number (forward-to number) or to the
  called subscriber‘s designated voice mailbox. If this feature is active, calls are forwarded regardless of
  the condition of the termination.

Call Waiting (CW)
  Call Waiting (CW) provides notification to a controlling subscriber of an incoming call while the
  subscriber‘s call is in the 2-way state. Subsequently, the controlling subscriber can either answer or
  ignore the incoming call. If the controlling subscriber answers the second call, it may alternate between
  the two calls.

Three-Way Calling (3WC)
  Three-Way Calling (3WC) provides the subscriber the capability of adding a third party to an
  established two-party call, so that all three parties may communicate in a three-way call. If either of

                                                                                                 Version 1.0
                                                    20           DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
  the two non-controlling parties to an established three-way call disconnects, the remaining party is re-
  connected to the controlling subscriber as a normal two-party call. If the controlling subscriber of a
  three-way call disconnects, the conference circuit and all other parties are released.

Calling Number Identification Presentation (CNIP)
  Calling Number Identification Presentation (CNIP) provides the number identification of the calling
  party to the called subscriber. One or two numbers may be presented to identify the calling party. The
  terminating network may receive the Calling Number Identification (CNI) as part of basic call setup.
  This CNI may include one or two Calling Party Numbers (CPNs), a Calling Party Sub address (CPS),
  Redirecting Numbers (RNs), and a Redirecting Sub address (RS). Sub address information is
  information other than the CPNs and Redirecting Number (RN) that identifies a particular party in a
  call. CNIP does not impact a subscriber‘s ability to originate calls or to receive calls.

Calling Number Identification Restriction (CNIR)
  Calling Number Identification Restriction (CNIR) restricts presentation of that subscriber‘s Calling
  Number Identification (CNI) to the called party. The terminating network may receive the Calling
  Number Identification (CNI) as part of basic call setup. This CNI may include one or two Calling Party
  Numbers (CPNs), a Calling Party Sub address (CPS), Redirecting Numbers (RNs), and Redirecting
  Sub addresses (RSs). Sub address information is information other than the CPNs and Redirecting
  Number (RN) that identifies a particular party in a call. CNIR does not impact a subscriber‘s ability to
  originate calls or to receive calls. *67 is commonly used to activate CNIR on a per call basis. *82 is
  commonly used to deactivate CNIR on a per call basis.

Call Transfer (CT)
  Call Transfer (CT) enables the customer to transfer an already established call to a third party.

Wireless Number Portability (WNP)
 Wireless Number Portability (WNP) allows the customer to change service providers and retain their
 Mobile Directory Number (MDN).

Emergency Services - E-911
 Emergency Services (9-1-1) permits a subscriber to dial 9 - 1 - 1 - SEND and be connected to a Public
 Safety Answering Point (PSAP) to request an emergency response from the appropriate agency (e.g.,
 fire, police, ambulance, poison control center, or suicide prevention center). The PSAP shall be the
 PSAP appropriate to the calling subscriber‘s current location. The wireless network provides ANI
 (Automatic Number Identification) and ALI (Automatic Location Information) to the PSAP, upon prior
 arrangement with the PSAP. A 9-1-1 call shall bypass any authorization restrictions or call origination
 restrictions features. Once the call is answered, the subscriber shall be able to communicate the type of
 emergency over a normal voice connection with the PSAP. (Encryption may be used over the air
 interface, but it must be removed on the connection to the PSAP.) A 9-1-1 call does impact a
 subscriber‘s ability to originate or receive calls while the 9-1-1 call is in progress. Flash privileges
 (features controlled by activating the SEND key, such as, Call Waiting, Three-Way Calling,
 Conference Calling, and Call Transfer) are suspended during the 9-1-1 call, except to re-connect a call
 placed on hold to place the 9-1-1 call. When the 9-1-1 call is released, the subscriber‘s normal calling
 capabilities are restored. Release occurs when either the subscriber or PSAP disconnects. Special
 release controls may apply, as described in Emergency Services Reconnect (9-1-1RC).

Court Ordered Surveillance/CALEA
  Court Ordered Surveillance/CALEA allows law enforcement to monitor voice and data activity of
  subscribers in real-time.
                                                                                                  Version 1.0
                                                     21           DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
Voice Mail Deposit (VMD)
  Voice Mail Deposit (VMD) permits a subscriber to have their unanswered calls deposited in a voice
  message system (VMS).

Message Waiting Notification (MWN)
 Message Waiting Notification (MWN) informs enrolled subscribers when a voice message is available
 for retrieval. MWN will use Short Message Service (SMS) to inform a subscriber of an unretrieved
 voice message(s). MWN does not impact a subscriber‘s ability to originate calls or to receive calls.

Voice Message Retrieval (VMR)
  Voice Message Retrieval (VMR) permits a subscriber to retrieve messages from a voice message
  system (VMS).

Ring Back Tones (RBT)
  Ring Back Tones (RBT) allows the calling party to hear music or other pre-recorded messages instead
  of normal ringing tones from the Network.

Short Message Service (SMS)
  Short Message Service (SMS) allows the customer to send or receive short text messages of 160
  characters or less. In addition, Enhanced Messaging Services (EMS) must be supported.

Over the Air Service Provisioning (OTASP)
  The Over the Air Service Provisioning (OTASP) feature allows a potential wireless service subscriber
  to activate (i.e., become authorized for) new wireless service, and allows an existing wireless
  subscriber to make changes in existing services without the intervention of a third party. OTASP
  typically includes the following:
           a. A call to the service provider customer service center.
           b. ―Over-The-Air‖ programming of Number Assignment Modules (NAMs), and optionally,
           service provider or manufacturer specific parameters (e.g., lock code, call timer).
           c. An Authentication Key Generation procedure.

Over the Air Parameter Administration (OTAPA)
  OTAPA allows a service provider to download Preferred Roaming Lists and other data to the handset
  over-the-air without any user intervention or knowledge.

Flexible Alerting (FA)
  Flexible Alerting (FA) causes a call to a Pilot Directory Number to branch the call into several legs to
  alert several termination addresses (wireless or wireline) simultaneously. The mobile telephones in the
  group may be alerted using distinctive alerting. Additional calls may be delivered to the FA Pilot
  Directory Number at any time. The first leg to be answered is connected to the calling party. The other
  call legs are abandoned.

  The members of an FA group are described by a list of termination addresses. Each termination address
  may either be a Directory Number or a MIN that uniquely identifies a mobile station. This allows MSs
  served by the same Home Location Register (HLR) as the FA pilot DN, MSs served by other HLRs
  (especially for serving multi-NAM phones of multiple service providers) and landline telephone
  numbers to be included.

  FA may be used for either a single user or multiple users. The difference between the two is in
  determining when the FA group is busy. In the single user case, the group is considered to be busy
                                                                                                Version 1.0
                                                    22          DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
  when one of the members is considered to be busy. In the multiple user case, the group is considered to
  be busy when all of the accessible members are considered to be busy. A member is considered to be
  busy when it cannot accept the presentation of another call. The busy condition of landline telephones
  cannot always be accurately determined.

Abbreviated Dialing (AD)
  Abbreviated Dialing (AD) allows a customer to call a Directory Number by entering less than the
  customary ten digits. Abbreviated Dialing numbers must be set up prior to using them. Most often, the
  customer has four digit dialing to mirror landline PBX dialing privileges when in the mobile
  environment. With four-digit dialing, the customer enters four digits in the keypad and the Network
  appends the rest of the digits to complete the call to a ten digit Directory Number. Abbreviated Dialing
  is an Enterprise feature.

Outbound Call Restrictions/Dialing Permissions
  Outbound Call Restrictions/Dialing Permissions refers to the type of calls the customer is allowed to
  originate. Examples are below. These categories may be joined in various combinations.
          - Local Calls Only
          - Selected Leading Digits of Directory Number (e.g., NPA-NXX for NANP)
          - National Long Distance
          - International
          - Single Directory Number (―Hot Line‖)
          - Toll Free

Vanity Numbers
 Vanity Numbers refers to the ability to call NANP Directory Numbers that are greater than 10 digits in
 length. For example, the number 1-800-SEE-AMERICA equates to 1-800-733-2637422. Special
 switch translations are required to complete calls to vanity Numbers such as this.

Inbound Call Restrictions
  Inbound Call Restrictions refers to the ability to receive inbound calls. Currently, there are only two
  choices for this feature: on or off.

Directory Assistance (411) with Release Link
  Directory Assistance (411) with Release Link refers to the ability for a customer to call 411 Directory
  Assistance, to interact with the attendant to get the desired number and to then have the call completed
  by the attendant. The trunks to the 411 Call Center are released from the call path when the call is
  completed to the final destination.

Feature Code Activation/De-Activation
  Feature Code Activation/De-Activation refers to the ability for the customer to invoke features using *
  codes. For example, the customer activates immediate call forwarding by dialing *71 and de-activates
  call forwarding by dialing *73.
  Note: * codes are used for Feature Code Activation/De-Activation. # codes are used for short code
  dialing. But, some legacy * codes are used for short code dialing such as *86 (Voice Mail retrieval)
  and locally allowed numbers such as *CG (Coast Guard or *24).
  Note: When other roaming partners roam on VZW, we translate their * codes into ANSI-41 FEATURE
  REQUEST messages that are sent to the HLR back in the home system for interpretation.

Short Code Dialing

                                                                                                Version 1.0
                                                    23          DRAFT – CDG ETO input to 3GPP2 SC-ATE TER
  Short Code Dialing refers to the ability for the customer to dial a short code such as #BAL, #PAY,
  #PMT, #MIN. The serving switch translates these short codes to a ten-digit directory number on a
  global basis and routes the call. # codes may be implemented locally only or globally throughout the
  VZW Network.
  Note: * codes are used for Feature Code Activation/De-Activation. # codes are used for short code
  dialing. But, some legacy * codes are used for short code dialing such as *86 (Voice Mail retrieval)
  and locally allowed numbers such as *CG (Coast Guard or *24).


Locally Allowed Abbreviated Dialing
  Locally Allowed Abbreviated Dialing refers to the ability for the customer to dial a local only, legacy
  short code such as *CG, *POL, *HOPE. The serving switch translates these short codes to a ten-digit
  directory number on a global basis and routes the call.
  Note: * codes are used for Feature Code Activation/De-Activation. # codes are used for short code
  dialing. But, some legacy * codes are used for short code dialing such as *86 (Voice Mail retrieval)
  and locally allowed numbers such as *CG (Coast Guard or *24).

N11 Dialing
  N11 Dialing refers to the ability for a customer to dial calls such as 311, 511, 611, 711 and 911 and
  receive the proper treatment.

Push DTMF to an IVR
  The customer needs the ability to send Dual Tone Multi Frequency (DTMF) tones to an IVR when in
  the VoIP environment.

Misdialed Calls - Play Proper Network Announcements
 When misdialed calls occur in the VoIP environment, the Network must play the proper Network
 Announcements based on the error conditions encountered.




                                                                                                Version 1.0
                                                   24           DRAFT – CDG ETO input to 3GPP2 SC-ATE TER

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:4
posted:6/22/2011
language:Dutch
pages:24