Convergence Services Using SIP Over Wi-Fi: Release 1 - 31 August 2005

Convergence Services using
SIP over Wi-Fi
Release 1 – 31st August 2005
FMCA Product Requirement

Definitions
Convergence Services Using SIP over
Wi-Fi Product Requirement Definitions
t
Disclaimer
The FMCA (and each of its members) is providing this information on an ‘as is’ basis and makes
no representations or warranties of any kind with respect to this information and disclaims all
such representations and warranties. In addition, the FMCA (and each of its members) makes no
representations or warranties about the accuracy, completeness, or suitability for any purpose of
the information. The information may contain technical inaccuracies or typographical errors. All
liability of the FMCA (and each of its members) howsoever arising for any such inaccuracies or
errors is expressly excluded to the fullest extent permitted by law. None of the contributors make
any representation or offer to licence any of their intellectual property rights to the other, or to any
third party. Nothing in this information or communication shall be relied on by any recipient.
Neither the FMCA nor any of its members will be liable for loss or damage arising out of or in
connection with the use of this information. This is a comprehensive limitation of liability that
applies to all damages of any kind, including (without limitation) compensatory, direct, indirect or
consequential damages, loss of data, income or profit, loss of or damage to property and claims
of third parties.
Notwithstanding the foregoing, none of the exclusions and limitations in the clause are intended
to limit any rights you may have as a consumer under local law or other statutory rights which
may not be excluded nor in any way to exclude or limit the FMCA’s (and each of its members’)
liability to you for death or personal injury resulting from its negligence or that of its members.
The contents of the FMCA Product Requirement Definitions (‘PRDs’) are proprietary to the FMCA and its members and are, unless
specifically indicated otherwise, protected by national and international copyright laws.
The FMCA PRD is published for reference purposes only, and not for general copying, distribution or alteration. The FMCA makes
no representation or warranty that the PRD is accurate or error free or that licences in intellectual property rights will be available to
those who implement any part of this PRD. The reader’s attention is drawn to the Disclaimer section of the PRD.
© 2005, FMCA, All Rights Reserved.

st
31 August 2005
Page 2 of 49
t
CONTENTS
1 Introduction 5
2 Definitions 6
3 Acronyms 10
4 Convergence Services Using SIP Over Wi-Fi 15
4.1 What Are Convergence Services Using SIP Over Wi-Fi? 15
4.2 Wi-Fi SIP PRD 16
5 Product Requirements 18
5.1 General End-to-End Aspects 18
5.2 SIP Functionality 19
5.3 Mobile Station 20
5.4 AP Requirements 39
5.5 Network Requirements 47
5.6 Corporate/Enterprise Connectivity 47
6 Appendix 1 – Summary of UMA Specification References 49

st
31 August 2005
Page 3 of 49
t
Acknowledgements
Wi-Fi Alliance:
Wi-Fi®, Wi-Fi Alliance®, the Wi-Fi logo, and the Wi-Fi ZONE logo are registered trademarks of
the Wi-Fi Alliance; and Wi-Fi CERTIFIED™, WMM™, WPA™, WPA2™, Wi-Fi ZONE™, the Wi-Fi
CERTIFIED logo, and the Wi-Fi Alliance logo are trademarks of the Wi-Fi Alliance.
UMA Technology:
To ensure alignment, this document bases its Mobile Station and Access Point RF requirements
on those originally recommended by the UMA Stage 2 Architecture specification. The use of
UMA recommendations is identified within the document through the use of italics and
references. In addition Appendix 1 highlights all the product requirements that are attributable to
the original UMA recommendations. It is acknowledged that this material may be copyright of the
participating partners of UMA Technology.
TIA:
CDMA 2000 is a registered trademark of the Telecommunications Industry Association (TIA-
User).
IEEE:
The IEEE logo, and other IEEE logos and titles are registered trademarks or service marks of
The Institute of Electrical and Electronics Engineers, Incorporated.
ETSI:
3GPP is a registered Trade Mark of ETSI in France and other jurisdictions.
Bluetooth Special Interest Group:

Bluetooth is a registered trademark of the Bluetooth Special Interest Group

st
31 August 2005
Page 4 of 49
t
1 Introduction
This is Release 1 of the Fixed-Mobile Convergence Alliance’s (FMCA) Wi-Fi SIP Product
Requirement Definitions (PRD), which provide the common product requirements for
Convergence Services using SIP over Wi-Fi (shortened to Wi-Fi SIP for the purpose of this
document).
For the purpose of this Product Requirement Definitions (PRD) document, SIP is an overarching
term covering pre-IMS and IMS based solutions. Specific SIP requirements will be presented in
PRD Release 2.
The FMCA is a global alliance of telecom operators whose objective is to accelerate the
development of Convergence products and services. With a rapidly growing membership base,
the FMCA represents approximately 500 million customers* who are set to benefit from the
development of Convergence services.
In this document, Convergence Services using SIP over Wi-Fi are defined as the use of wireless-
enabled handsets or mobile stations for both enterprise and consumer voice and data
applications, with multimedia session initiation, service signalling and control being performed by
SIP.
With Wi-Fi there are two underlying technology options: Wi-Fi GAN (UMA) and Wi-Fi SIP.
Wi-Fi GAN (UMA) may be positioned as an interim option - for those operators who have already
invested in 3GPP cellular networks or MVNOs targeting consumer customers - until such time
when Wi-Fi SIP becomes a full open standard and migration to this Convergence technology can
be initiated.
The FMCA’s focus over the coming months will be on the phased evolution of the Wi-Fi SIP PRD
document and active engagement with Standard Development Organisations, Industry Alliances
and the Vendor Community to present the common product requirements across the entire
FMCA membership base.
The aim being to ensure the continued alignment of the FMCA Product Requirement Definitions
with existing and future standards and certification programmes, especially as the FMCA
Technical Working Group works to produce Release 2 of the FMCA Wi-Fi SIP Product
Requirement Definitions, which is scheduled for March 2006 and will take the various
requirements to the more detailed level required to build a SIP based Convergence product.
It should be noted that the FMCA is not a Standard Development Organisation (SDO). The aim of
the FMCA is to comply with existing and future technical standards and certifications. To this
extent, the FMCA has or is in the process of engaging with the Wi-Fi Alliance, 3GPPTM, ETSI-
TISPAN and IEEE.
Additional SDOs/Fora as well as Vendors will be engaged as the FMCA Product Requirement
Definitions for Wi-Fi SIP evolve further. Vendors and SDOs/Fora wishing to review the FMCA
PRD should contact, in the first instance, the FMCA Office, expressing their interest:
Rodrigo Donazzolo
FMCA Programme Director
The FMCA Office
Rodrigo.donazzolo@thefmca.com
* As of 31st August 2005.


st
31 August 2005
Page 5 of 49
t
2 Definitions
For the purposes of this document, the following terms and definitions apply:
2G Second Generation cellular mobile technology/systems.
2.5G Enhanced 2G cellular technologies, such as higher speed

data services, regarded as interim between 2G and 3G,
e.g. GPRS support.
3G Third Generation cellular mobile technology is a term used
to describe a range of new air interfaces which includes,
amongst others, W-CDMA, CDMA-2000 and TD-SCDMA.
Access Point A wireless-LAN base station. An Access Point (AP) acts as
the communication hub for users of a wireless device to
connect to services such as the internet, PSTN and PBX
via fixed backhauls.
Associate The process of obtaining a registered connection between
a Mobile Station (MS) and a wireless AP.
Attach The process of obtaining a registered connection between
a MS and a cellular base station.
Backhaul Network backhaul from wireless Access Point e.g. ADSL,
cable, etc. Transmission Link between AP and the core IP
network.
Broadband Access Network Broadband network backhaul from wireless Access Point,
e.g. ADSL, cable, etc.
Cellular/cellular network Use of 2G, 2.5G and 3G networks for voice and data
services.
Cellular mode The Wi-Fi SIP MS has registered with a wide area cellular
network.
Cellular only mode When the MS is in cellular-only mode, the service can only
be accessed via a wide-area cellular network.
Cellular preferred mode When the MS is in cellular-preferred mode, the MS shall
provide service via the wide-area cellular network when in
coverage. When there is no cellular coverage, the MS shall
register and provide service via the wireless network (if
available). Note that the MS shall not automatically switch
mode if this will terminate a voice call in progress.
Corporate/enterprise A device accessing a corporate or enterprise Wi-Fi
Wi-Fi access network.

st
31 August 2005
Page 6 of 49
t
Coverage Zone of coverage created by one or multiple wireless

Access Points.
Device A Mobile Station which could take several form factors,
e.g. a mobile handset, PC or a PDA.
Dual mode device A device or MS capable of operating in both wireless and
cellular modes for the context of this PRD.
Gateway A combined DSL/cable modem, router and Access Point
with additional capabilities, such as NAT, NAPT and
DHCP.
Guest Wi-Fi Service The capability for a gateway or Access Point to offer guest
Wi-Fi services to visiting users.
Handover The seamless in-call/in-session movement of an MS from
wireless to cellular operation, or vice versa, or in-call/in-
session movement from one AP to another. Voice calls
and data session continuity are required.
• Handover-in = MS moving from cellular to Wi-Fi.
• Handover-out = MS moving from Wi-Fi to cellular.
• Handover AP = MS moving from one Wi-Fi AP to
another.
Public hotspot A zone of continuous public access to wireless internet
services.
Incoming call A call originating from the fixed or mobile network or
another Wi-Fi SIP MS towards the Wi-Fi SIP MS.
Internet service A service provided via internet protocols. Examples of
these services include SIP telephony, multimedia,
worldwide web and email.
Inter AP transfer The process by which the MS moves from one AP to
another, while maintaining service. Inter AP transfer refers
to movement between both APs on the same subnet and
between those on different subnets.
Location services Value added service capabilities based on a device’s
physical location.
Mobile Station A device which could take several form factors, e.g. a
mobile handset, PC or a PDA.
Optimal routing The capability to route traffic based on key factors such as
call tariffs and location (e.g. in a Wi-Fi hotspot).
Outgoing call A call originating from the Wi-Fi SIP MS towards a fixed or
mobile network or another Wi-Fi SIP MS.

st
31 August 2005
Page 7 of 49
t
Presence services Service capabilities based on a user’s presence, e.g.

user’s status – busy in a meeting, available, travelling etc.
Quality of Service The collective effect of service characteristics,
(QoS) performances and capabilities that determine a user’s
degree of satisfaction. For example, the impact of traffic
prioritisation on latency, error rate, etc.
Roaming The process which enables a device to be used outside
the coverage area of the home network (wireless or
cellular) by means of a visited network.
Router A functional block that determines the next network point
to which a data packet should be forwarded en route to its
destination.
Roving The seamless action of re-selection between cellular
access technology and wireless access technology for a
Wi-Fi SIP MS in an idle mode.
• Rove-in – MS reselects from cellular to wireless.
• Rove-out – device reselects from wireless to cellular.
Seamless Seamless is defined as there being no perceptible break in

voice or data transmission due to handover (from the
calling party or the called party's perspective).
Session mobility The seamless movement of in-call sessions (both voice
and data) between Wi-Fi Access Points, Wi-Fi hotspots
and cellular networks.
SIP Session Initiation Protocol. In this document it is generally
used to refer to systems which use SIP to set-up and tear-
down sessions over wireless networks. These SIP systems
are initially expected to be based around the basic IETF
SIP standards, with a migration to the 3GPP IMS
implementation of these standards over time.
SIP Profile Set of SIP subscription parameters such as SIP userID,
authentication ID and password, codec settings, SIP
server address, etc.
Telecommunication Service A service offered by a service provider to satisfy an end
user’s specific telecommunication requirement.
Trusted A service in which the user has the firm belief in the
competence of an entity to act dependably, securely and
reliably within the context of service provisioning and
billing.

st
31 August 2005
Page 8 of 49
t
Wireless For the purpose of this paper, wireless enabled devices or

MS (IEEE 802.11a, b, g, h, n, j) for both enterprise and
consumer voice (VoIP) and data applications.
Wireless Fidelity A wireless-LAN technology based on IEEE 802.11
(Wi-Fi®) specifications. Wi-Fi is a registered trademark of the Wi-Fi
Alliance.
Wi-Fi association Set-up signalling and handshaking between a device and a
Wi-Fi AP e.g. SSID, security association, channel
allocation, data rates, capabilities, etc.
Wireless Profile The Wireless Profile is a set of service related parameters
that enables a Wi-Fi device to associate and then access a
Wi-Fi network. For example, the profile could contain
details associated with AP SSIDs, locations, supported
protocols, security options, etc.
WiMAX World Interoperability for Microwave Access is a
broadband wireless access technology based on IEEE
802.16 standard.
Wireless mode The Wi-Fi SIP device has registered with a network using
Wi-Fi access.
Wireless-only mode When the MS is in wireless-only mode – the service can
only be accessed when in wireless coverage.
Wireless-preferred mode The MS shall register to the SIP server when in wireless
coverage and SIP will be the default means of making
outgoing connections. The operator will define whether the
cellular radio interface remains simultaneously active or
not in this mode.

st
31 August 2005
Page 9 of 49
t
3 Acronyms
This document uses the following acronyms:

2G Second Generation
3GPP Third Generation Partnership Project
3G Third Generation
AAA Authentication, Authorisation And Accounting
ADSL Asymmetric Digital Subscriber Line
ALG Application Level Gateway
AMR Adaptive Multi-Rate speech encoding
AP Access Point
B2BUA Back to Back User Agent
BAOC Barring of all outgoing calls
BIC-ROAM Barring of all Incoming Calls when Roaming outside HPLMN
BOIC Barring of Outgoing International Calls
BOIC-ex HC Barring of all outgoing international calls (roaming) except to HPLMN
BSSID Broadcast SSID
CAC Connection Admission Control
CCMP Counter Mode with Cipher Block Chaining Message Authentication
Code Protocol
CDMA Code Division Multiple Access
CE Conformité Européenne
CFB Call Forwarding on mobile customer Busy
CFU Call Forwarding Unconditional
CFNRc Call Forwarding on mobile Customer Not Reachable
CFNRy Call Forwarding on No Reply
CLI Caller Line Identification
CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Restriction
CNG Comfort Noise Generator
COS Class Of Service
CPU Central Processing Unit
CSCF Call State Control Function
CSD Circuit Switched Data
CW Call Waiting
DHCP Dynamic Host Configuration Protocol
Diffserv Differentiated Services
DNS Domain Name Server
DSCP Differentiated Services Code Point

st
31 August 2005
Page 10 of 49
t
DSCP/ToS Differentiated Services Code Point / Type of Service

DSL Digital Subscriber Line
DTMF Dual Tome Multi Frequency
EAP Extensible Authentication Protocol
EAPOL EAP over LAN
EAP-AKA Extensible Authentication Protocol – Authentication and Key Agreement
EAP-PEAP Extensible Authentication Protocol – Protected Extensible
Authentication Protocol
EAP-TLS Extensible Authentication Protocol – Transport Layer Security
EAP-TTLS Extensible Authentication Protocol – Tunnelled TLS
EAP-SIM Extensible Authentication Protocol – Subscriber Identity Module
EDCA Enhanced Distributed Channel Access (IEEE 802.11e)
EIRP Effective Isotropic Radiated Power
EFR Enhanced Full Rate
FMC Fixed-Mobile Convergence
FMCA Fixed-Mobile Convergence Alliance
GERAN GSM EDGE Radio Access Network
GPRS General Packet Radio Service
GSM Global System for Mobile communications
HCCA Hybrid Controlled Channel Access (IEEE 802.11e)
HLR Home Location Register
HMACL Hash Message Authentication Code
HPLMN Home Public Land Mobile Network
HTML HyperText Mark-up Language
HTTP HyperText Transfer Protocol
HTTPS HTTP over SSL
HSS Home Subscriber Server
IAPP Inter-Access Point Protocol
ICMP Internet Control Message Protocol
ICNIRP International Commission on Non-Ionising Radiation Protection
ICSA International Computer Security Agency
IGMP Interior Group Management Protocol
IKE Internet Key Exchange version 2
IMEI International Mobile station Equipment Identity
IMS IP Multimedia Subsystem (3GPP)
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IP-CAN IP Connectivity Access Network (3GPP)
Ipsec Internet Protocol Security
IRAP International Roaming Access Protocol

st
31 August 2005
Page 11 of 49
t
ISIM IM Subscriber Identity Module

ISM Industrial, Scientific and Medical
ISP Internet Service Provider
LAES Lawfully Authorised Electronic Surveillance
LAN Local Area Network
MAC Medium Access Control
MBMS Multimedia Broadcast Multicast Services
MEID Mobile Equipment ID
MIKEY Multimedia Internet KEYing
MIMO Multiple Input Multiple Output
MMS Multimedia Messaging Service
MNC Mobile Network Code
MNO Mobile Network Operator
MPTY Multi Party
MS Mobile Station
MVNO Mobile Virtual Network Operator
NAPT Network Address Port Translation
NAT Network Address Translation
OFDM Orthogonal Frequency Division Multiplexing
OMA Open Mobile Alliance
OS Operating System
OSPF Open Shortest Path First protocol
OSS Operational Support System
OTA Over The Air
PBX Private Branch Exchange
PDA Personal Digital Assistant
PDG Packet Data Gateway
PEAP Protected Extensible Authentication Protocol
PER Packet Error Rate
PLC Packet Loss Concealment
PMK Pair Wise Master Key (IEEE 802.11i)
P-CSCF Proxy Call State Control Function
PPPoA Point-to-Point Protocol over ATM
PPPoE Point-to-Point Protocol over Ethernet
PSAP Public Safety Answering point
PSK WPA Pre-Shared Keys
PSTN Public Switched Telephone Network
PQCBWFQ Priority Queue Class Based Weighted Fair Queuing
QoS Quality of Service
RADIUS Remote Access Dial-up User Service
RAN Radio Access Network

st
31 August 2005
Page 12 of 49
t
RIP Routing Information Protocol

RTP Real-time Transport Protocol
R-UIM Removable User Identity Module
SDP Session Description Protocol
SIP Session Initiation Protocol
SIM Subscriber Information Module
SMS Short Message Service
SOHO Small Office Home Office
SRTP Secure RTP
STRP Signalling Type Rearrangement Pref. Mkr
SSID Service Set Identifier
SSL Secure Sockets Layer
TCP Transmission Control Protocol
TDM Time Domain Multiplexing
TD-SCDMA Time Division – Synchronous Code Division Multiple Access
TISPAN Telecommunications and Internet Services and Protocols for Advanced
Networks (ETSI)
TKIP Temporal Key Integrity Protocol
TLS Transport Layer Security
TTY Teletype
UDP User Datagram Protocol
UMA Unlicensed Mobile Access
URL Uniform Resource Locators
USB Universal Serial Bus
USIM Universal Subscriber Identity Module
USSD Unstructured Supplementary Services Data
UTRAN Universal Terrestrial Radio Access Network
VAD Voice Activity Detector
VLAN Virtual Local Area Network
VoIP Voice Over IP
VoWLAN Voice Over WLAN
VPN Virtual Private Network
WAN Wide Area Network
WBA Wireless Broadband Alliance
WCC Wireless Cellular Convergence
W-CDMA Wideband Code Division Multiple Access
WDS Wireless Distribution System
WEEE Waste from Electrical and Electronic Equipment
WEP Wired Equivalent Privacy
Wi-Fi® Wireless Fidelity (registered trademark of the Wi-Fi Alliance)
WiMAX World Interoperability for Microwave Access, and IEEE 802.16

st
31 August 2005
Page 13 of 49
t
WLAN Wireless Local Area Network

WME Wireless Media Extensions
WMM Wi-Fi MultiMedia
WMM-SA Wi-Fi MultiMedia – Scheduled Access
WPA Wi-Fi Protected Access
WRED Weighted Random Early Discard

st
31 August 2005
Page 14 of 49
t
4 Convergence Services Using SIP Over Wi-Fi
4.1 What Are Convergence Services Using SIP Over Wi-Fi?
Presently, both cellular and fixed networks are moving towards the converged use of the Session
Initiation Protocol (SIP) for session/service initiation and signalling.
For the purpose of this Product Requirement Definitions (PRD) document, SIP is an overarching
term covering pre-IMS and IMS based solutions. Specific SIP requirements will be presented in
PRD Release 2. It is acknowledged that in terms of IMS 3GPP and 3GPP2 specifications will be
harmonised.
Convergence Services using SIP over Wi-Fi (shortened to ‘Wi-Fi SIP’ within this document) are
defined as the use of wireless-enabled handsets or mobile stations for both enterprise and
consumer voice and data applications, with multimedia session initiation, service signalling and
control being performed by SIP. It should be noted that there may be scenarios where
corporate/enterprises may require their own local SIP/IMS feature sets (application and SIP
servers). In addition, there may be use of HTTP, HTTPS and HTML for support applications such
as remote management, self-care and authentication. The provision of seamless access will be
enabled through Wi-Fi connectivity to public hotspots, consumer Access Points and
corporate/enterprise Access Points.
When connected to an Access Point, a Wi-Fi SIP call can present a fixed, PBX or mobile calling
line identity depending on the operator implementation or customer requirement. When in cellular
coverage, the Wi-Fi SIP call can either present the same calling line identity as in Access Point
range or a mobile calling line identity.
Wi-Fi SIP supports seamless in-call handover from the Access Point to the cellular network and
from cellular to Access Point. In addition, Wi-Fi SIP shall also support seamless in-call handover
between Access Points within the same network. These seamless in-call handover processes
are currently proprietary. Wi-Fi SIP supports 3GPP and 3GPP2 cellular networks and cable, DSL
and WiMAX (IEEE 802.16d-2004) from the Access Point.
It should be noted that for the purpose of this document, the initial Wi-Fi SIP requirements will
just refer to existing and emerging IEEE 802.11 wireless standards and not WiMAX IEEE
802.16e at this time. In the future, SIP/VoIP support over WiMAX IEEE 802.16e product
requirements e.g. air interface aspects, will need to be considered.
The initial concept behind Wi-Fi SIP is shown over the page in Figure 1. It should be noted that
Figure 1 represents the initial view, and it is acknowledged that as cellular networks evolve
towards IMS, SIP support will also be available over the cellular access network. It is also
acknowledged that as fixed networks evolve towards ETSI TISPAN NGN, one common IMS,
independent from the access network will be supported.

st
31 August 2005
Page 15 of 49
t
Figure 1 – Initial Wi-Fi SIP Concept
4.2 Wi-Fi SIP PRD
Today, Bluetooth is a technology that can provide Convergence services to the consumer
market primarily due to the current common availability and consumer pricing of Bluetooth
enabled handsets. However, Wi-Fi is seen as the next step for Convergence services due to its
ability to offer increased coverage, support for Wi-Fi hotspot connectivity and enhanced data
capabilities.
With Wi-Fi there are two underlying technology options: Wi-Fi GAN (UMA) and Wi-Fi SIP.
Wi-Fi GAN (UMA) may be positioned as an interim option - for those operators who have
already invested in 3GPP cellular networks or MVNOs targeting consumer customers - until
such time when Wi-Fi SIP becomes a full open standard and migration to this Convergence
technology can be initiated.
As both cellular and fixed networks move towards the converged use of SIP for service
establishment and signalling, 3GPP/3GPP2 IMS compliant Wi-Fi SIP should be considered as
the long-term goal.
It is perceived that Wi-Fi SIP will offer the following key benefits:
• tighter integration with next generation IP and SIP based communications
• closer alignment with corporate/enterprise requirements
• convergence of voice and high speed data capabilities

st
31 August 2005
Page 16 of 49
t
• video/multimedia capabilities
Both Wi-Fi SIP and Wi-Fi GAN (UMA) will provide options to facilitate the most cost effective
method of delivering voice and data. For example, the ability to route local traffic via a lower
cost wireless platform when available, thus preserving cellular capacity for wide area coverage
and, in doing so, optimising network usage and increasing economies of scale.

st
31 August 2005
Page 17 of 49
t
5 Product Requirements
This section will define the product requirements for the following five key areas for Wi-Fi SIP:
• general end-to-end aspects;
• SIP functionality;
• Mobile Station functionality;
• Access Point functionality;
• Network Connectivity.
Within this section the word ‘shall’ denotes a mandatory requirement and the word
‘should’ denotes a desirable requirement.
5.1 General End-to-End Aspects
5.1.1 The solution shall offer consumer and business customers high quality value added
Convergence services through a Wi-Fi SIP service that can facilitate the most cost
effective method of delivering communications. For example, the ability to route local
traffic, when available, via a lower cost wireless platform, thus preserving cellular
capacity for wide area coverage. It is appreciated that the business strategies associated
with optimal routing will need to be discussed, e.g. global roaming alliances. In addition,
it is recognised that there may be scenarios where corporate/enterprises will require their
own local SIP feature sets to facilitate such capabilities.
5.1.2 APs shall offer the maximum possible coverage to minimise the number of APs required
to cover both business and consumer premises and hence reduce installation costs.
However, it is recognised that, in the enterprise environment, there will be a trade-off
between AP coverage and call density due to the fact that APs can only support a limited
number of simultaneous calls. It is also recognised that Wi-Fi power level regulations will
vary from country to country.
5.1.3 The Wi-Fi SIP MS and associated Wi-Fi APs shall ensure that the wireless mode voice
quality, for both incoming and outgoing calls, shall be comparable or better than the
voice quality obtained with good-coverage cellular (including delay and echo). The
FMCA recognises that certain aspects of this requirement may be met through emerging
Wi-Fi Alliance Wireless Cellular Convergence (WCC) and Voice over Wi-Fi certifications.
More details will follow in subsequent PRD releases.
5.1.4 The Wi-Fi SIP MS and associated Wi-Fi APs shall support seamless in-call/in-session AP
to AP handovers and seamless in-call/in-session handover between Wi-Fi AP and
cellular networks, and vice-versa, with balancing of voice quality. Voice call continuity
shall be supported. The FMCA recognises that certain aspects of this requirement may
be met through emerging Wi-Fi Alliance Wireless Cellular Convergence (WCC), Voice

st
31 August 2005
Page 18 of 49
t
over Wi-Fi and Public and Managed Access certifications, more details will follow in
subsequent PRD releases.
5.1.5 The MS shall support idle seamless roving between Wi-Fi and cellular networks (and vice
versa) and inter AP transfers.
5.1.6 The MS shall be able to connect to the Wi-Fi SIP service with no user interaction without
compromising security.
5.1.7 Wi-Fi SIP services shall support the capability for Operators to specify call admission
control policies, e.g. list of incoming/outgoing calls not to be accepted and the ability to
restrict services to wireless or cellular access.
5.1.8 Wi-Fi GAN (UMA) and Wi-Fi SIP handset specifications should be aligned to facilitate
common physical devices that can be modified by software and configuration parameters
to operate with SIP or UMA, depending on which service the user is subscribed to. For
more information on Wi-Fi GAN refer to the FMCA Wi-Fi GAN (UMA) PRD.
5.1.9 Wi-Fi SIP services and MS should be wireless Access Point agnostic and hence support
seamless connection to public Wi-Fi hotspots, private Wi-Fi enabled home hubs, Wi-Fi
enabled teleworker APs and corporate and enterprise Wi-Fi networks.
5.2 SIP Functionality
PRD release 2 will define SIP architecture requirements. For example, appropriate components
of 3GPP SIP/SDP Profile as defined in 3GPP TS 24.229 V6.6.0 (2005-03) and ETSI TISPAN
SIP/SDP Profile (WI TISPAN-03019) or 3GPP2 SIP/SDP support as defined in TIA-873.

st
31 August 2005
Page 19 of 49
t
5.3 Mobile Station
5.3.1 General
5.3.1.1 The MS shall be, at the minimum, a dual mode cellular and wireless device. The FMCA
recognises that certain aspects of this requirement may be met through emerging Wi-Fi
Alliance Wireless Cellular Convergence (WCC) certifications. More details will follow in
5.3.1.2 The MS shall support the capability for Voice over IP (VoIP) in wireless mode.
5.3.1.3 The MS shall provide a common user interface in wireless and cellular modes.
5.3.1.4 The MS should support at least 10 additional SIP Wi-Fi only profiles (subscriptions), in
addition to the primary converged profile. For example existing SIP terminals and
softphones allow multiple SIP profiles. VoIP providers allow users to subscribe to several
different telephone numbers, typically in different geographical areas. Each number is
stored in a separate SIP profile. Users would expect similar functionality from a Wi-Fi SIP
MS.
5.3.1.5 The MS should support the capability to be used as a modem, in both cellular and
wireless modes, via a 'tethered' data port connection to another device, e.g. a PC.
5.3.2 Power-on
5.3.2.1 The MS shall support the capability to enforce subscriber authentication at power-on, for
example through the use of a PIN.
5.3.2.2 The MS shall scan for wireless and cellular coverage at power-on, as per mode settings.
For example, if MS is in wireless-only mode then only a wireless scan shall be performed.
The FMCA recognises that certain aspects of this requirement may be met through
emerging Wi-Fi Alliance Wireless Cellular Convergence (WCC) certifications. More
details will follow in subsequent PRD releases.
5.3.2.3 The MS shall have the capability to display to the user the available wireless networks it
can connect to. The FMCA recognises that certain aspects of this requirement may be
met through emerging Wi-Fi Alliance Wireless Cellular Convergence (WCC) certifications.
5.3.3 Connection Establishment
5.3.3.1 The MS shall automatically associate to a Wi-Fi AP which is in range, subject to the Wi-Fi
signal being of sufficient quality to meet the service requirements and the device being in
wireless-preferred or wireless-only-mode. The FMCA recognises that certain aspects of
this requirement may be met through emerging Wi-Fi Alliance Wireless Cellular
Convergence (WCC) certifications. More details will follow in subsequent PRD releases.

st
31 August 2005
Page 20 of 49
t
5.3.3.2 The MS shall automatically attach to a cellular network if it is not in range of a Wi-Fi AP or
a suitable public Wi-Fi hotspot, dependent on users’ preference of wireless-preferred or
wireless-only modes.
5.3.3.3 The MS shall automatically attach to a cellular network if it is in cellular-only-mode.
5.3.3.4 The MS shall support the capability to configure the preference for connectivity, e.g.
cellular or wireless, for both making and receiving calls/data. It is recognised that, in
some scenarios, this may result in users being connected to both networks at the same
time.
5.3.3.5 The MS shall provide seamless support for international cellular and Wi-Fi service
provider roaming.
5.3.3.6 Dependent on deployment scenarios for pre-IMS solutions, the MS should provide the
ability to simultaneously connect to both wireless and cellular access.
5.3.4 Connection to Wi-Fi AP
5.3.4.1 The MS shall support connectivity to the following types of Wi-Fi APs: private/home APs
and gateways, public Wi-Fi hotspots and enterprise/corporate APs and temporary
portable APs, e.g. USB dongle for laptops. The FMCA recognises that certain aspects of
this requirement (e.g. hotspots) may be met through emerging Wi-Fi Alliance Public and
Managed Access certifications. More details will follow in subsequent PRD releases.
5.3.4.2 The MS shall support the capability for users to gain guest access to Wi-Fi SIP
service/networks via wireless APs or gateways that they may be visiting.
5.3.4.3 The MS shall enforce secure mutual authentication at the wireless level between the
device and the Wi-Fi SIP network. The FMCA recognises that certain aspects of this
requirement may be met through emerging Wi-Fi Alliance Public and Managed Access
certifications. More details will follow in subsequent PRD releases.
5.3.4.4 The MS shall support air interface encryption which is at least as secure as cellular
ciphering.
5.3.4.5 The MS shall monitor the signal quality at the wireless layer.
5.3.4.6 The MS shall be capable of associating to an AP which is broadcasting its SSID.
5.3.4.7 The MS shall be capable of associating to an AP which is not broadcasting its SSID.
5.3.4.8 The MS should be able to access AP supporting multiple SSIDs and VLANs.
5.3.4.9 When the MS successfully associates and authenticates with the AP for the first time, it
shall store the association/authentication details within a MS wireless profile.
5.3.4.10 The MS shall be capable of storing a minimum of 32 wireless

profiles/associations and differentiate between them based on Wi-Fi parameters such as

st
31 August 2005
Page 21 of 49
t
SSID and MAC address. Operators shall have the ability to restrict the maximum number
of WLAN associations. The user shall have the ability to label the wireless profile; the
default shall be the SSID.
5.3.4.11 The MS shall be able to set and store an order of preference against all the
available wireless networks/SSID.
5.3.4.12 The MS shall attempt to associate to Wi-Fi networks in the order determined by
the wireless profile priorities.
5.3.4.13 The MS shall support the option of connecting to a pre-configured SSID, if

available as first priority, if such an SSID has been pre-configured in the MS.
5.3.4.14 If the MS detects a wireless network that it can use, and with no other higher
priority wireless networks available, the device shall automatically attach to that wireless
network - subject to the wireless signal being of sufficient quality to meet the service
requirements, and subject to the device being in wireless-preferred or wireless-only
mode.
5.3.4.15 After the MS has successfully attached for the first time to AP, for all types of AP,
MS to AP Authentication on connection shall be seamless and shall not require any
keystroke entry on the MS to attach to the service.
5.3.4.16 If a MS successfully associates to an AP but fails to register successfully to the

SIP server after a number of registration attempts (number of attempts to be defined by
the operator), the MS should attempt the registration via another AP. AP association and
subsequent SIP registration attempts should be repeated until all available APs have
been attempted. The number of AP association attempts, the number of SIP registration
attempts per AP, the maximum number of APs to be attempted and the timing intervals
shall be Operator configurable.
5.3.5 Connection to Network
5.3.5.1 The MS shall support connection to the network from any/all of the following:
• enabled enterprise site;
• cellular network;
• public wireless hotspot;
• private AP, e.g. home;
• temporary portable APs, e.g. USB dongles for laptops;
• other IP networks.
5.3.5.2 If the MS is put into a sleep mode, the application should retain any wireless and/or
cellular connections. In the event of an incoming call, the application should automatically
wake the device up and indicate the incoming call.
5.3.5.3 The device shall support a de-registration process to detach from the core VoIP network.
5.3.5.4 The MS should support independent configurations (DNS names) for voice (S/P-CSCF),
Presence (S/P-CSCF – Presence Application Server) and IM server (S/P-CSCF – IM

st
31 August 2005
Page 22 of 49
t
Application Server). This option shall be configurable by the operator, if feature is

provided.
5.3.5.5 The home Operator should support the ability to re-direct SIP registrations to another SIP
proxy.
5.3.5.6 The MS shall support DNS resolution of the SIP server according to RFC 2782 (DNS
SRV).
5.3.5.7 The MS should support DNS resolution of the Presence server according to RFC 2782
(DNS SRV).
5.3.5.8 The MS should support DNS resolution of the IM server according to RFC 2782 (DNS
SRV).
5.3.6 Presence
5.3.6.1 The device shall support presence capabilities in both wireless and cellular modes.
Preferences for implementation options (e.g. 3GPP, 3GPP2, OMA) shall be defined in
subsequent FMCA PRD releases. Currently they are Operator specific.
5.3.6.2 The device should support presence capabilities so that it can update core presence
servers when in wireless mode.
5.3.6.3 The device should support presence capabilities so that it can update core presence
servers when in cellular mode.
5.3.6.4 It should be possible for presence to be updated by the user using the MS, e.g. change of
availability status.
5.3.6.5 The MS should support the ability to automatically change the device status to ‘Call
Active’ or similar when the user establishes a voice call. This feature shall be configurable
by the user (enable/disable).
5.3.7 Applications, Services and Features
5.3.7.1 MS features shall be similar to those of an equivalent cellular MS, or an equivalent PDA.
Examples of these features are: address book, menus, speed dial capability, language
support, voice activity detection, battery level indication, loudspeaker/hands-free
capability, alerting mechanism, accessories, DTMF, volume control, time/date display,
SMS, predictive text, MMS, Java games, colour display, etc.
5.3.7.2 Real-time OS: the client device shall support multi-threading and support for real-time
applications such as VoIP.
5.3.7.3 Mid-tier and high-end MS shall enable the use of productivity applications such as
enterprise email, calendaring, and contacts (including speed dialling from the contacts
list). For example, the ability to use various email applications on MS and support speed
dialling from contact list.

st
31 August 2005
Page 23 of 49
t
5.3.7.4 Mid-tier and high-end MS should support Presence and Contact/Buddy lists.
5.3.7.5 It shall be possible for all MS applications, firewalls and antivirus software, etc. to be
installed on the MS during manufacture or post manufacture. Both methods shall be
supported.
5.3.7.6 It should be possible for all MS applications, firewalls and antivirus software etc, to be
provisioned over the air.
5.3.7.7 It shall be possible for access to the Wi-Fi SIP service from the MS to be disabled
remotely by the operator.
5.3.7.8 The MS shall support Instant Messaging in wireless and cellular modes.
5.3.7.9 The MS shall support MMS and SMS in both wireless and cellular modes, irrespective of
being in-call/in-session (voice/data) or idle. These features shall be enabled or disabled
based on an individual Operator requirements.
5.3.7.10 CLIP on SMS messages sent/received in wireless mode shall be as per the
cellular service.
5.3.7.11 Roving or handover shall not cause the sending or receiving of an SMS to fail i.e.
from a user’s perspective, and an SMS should not be lost due to roving or handover.
5.3.7.12 When in cellular mode, the MS shall use cellular data services to provide the
same services at the best obtainable performance that is available in wireless mode.
5.3.7.13 The MS should be able to indicate to the application layer the access mechanism
in use.
5.3.7.14 For mid to high-end enterprise and corporate scenarios, an MS application

should allow users to use a ‘click to dial’ type system to reach the contacts on the
corporate directory system. This shall be available in wireless and cellular modes. ‘Click
to dial’ is the ability for a user to access a corporate directory (held in the enterprise
network), and scroll or search through this directory to find a contact which can then be
dialled with one keystroke. The MS should support ‘click to call’ or ‘click to call back’
functions.
5.3.7.15 Users shall be able use the MS to set any call diversion methods, as per current
cellular functionality, such as divert when busy, divert when not reachable.
5.3.7.16 The MS shall allow a user’s status to be reflected in contact information. This
shall be available in wireless and cellular modes. The MS shall support the capability for
the user to enable/disable this feature.
5.3.7.17 The MS shall support USSD in 3GPP networks.
5.3.7.18 The MS shall support DTMF in cellular mode and in wireless mode.

st
31 August 2005
Page 24 of 49
t
5.3.7.19 The supplementary services that are defined in the 3GPP TS 22 series
specifications or TIA-737 dependent on regional/in country requirements, shall be
available and consistent in both modes. These supplementary services shall include:
– Calling line identification presentation (CLIP)
– Calling line identification restriction (CLIR)
– Call forwarding unconditional (CFU)
– Call forwarding on mobile customer busy (CFB)
– Call forwarding on no reply (CFNRy)
– Call forwarding on mobile customer not reachable (CFNRc)
– Call waiting (CW)
– Call Hold
– Multi Party (MPTY)
– Barring of all outgoing calls (BAOC)
– Barring of outgoing international calls (BOIC)
– Barring of outgoing calls to premium rate or other numbers
– Barring of all outgoing international calls (roaming) except to HPLMN (BOIC-ex
HC)
– Barring of all incoming calls when roaming outside HPLMN (BIC-ROAM).

st
31 August 2005
Page 25 of 49
t
5.3.7.20 MS should support value added Location Based Services.
5.3.7.21 MS should support video telephony services.
5.3.7.22 For 3GPP2 networks, the MS should support over-the-air technology as a

facilitator for remote device configuration e.g. as per IS-683 over SMS or IP.
5.3.7.23 The MS should support IM applications (or cover in list of services).
5.3.7.24 The MS should support native IP access including WAP sessions.
5.3.7.25 The MS should support the capability to divert calls based on presence
information. For example, business calls may be diverted to business voice mail when the
MS is on home Wi-Fi.
5.3.8 Voice Calls
5.3.8.1 The MS shall support incoming and outgoing calls over cellular networks.
5.3.8.2 The MS shall support incoming and outgoing voice calls over wireless networks. The
Wi-Fi Alliance Wireless Cellular Convergence (WCC) and Voice over Wi-Fi certifications.
5.3.8.3 The MS shall always remain receptive to inbound calls and to be able to respond quickly
to dialled outgoing call requests. The FMCA recognises that certain aspects of this
requirement may be met through emerging Wi-Fi Alliance Wireless Cellular Convergence
(WCC) and Voice over Wi-Fi certifications. More details will follow in subsequent PRD
releases.
5.3.8.4 The MS shall support Real Time Protocol (RTP) for wireless mode voice calls.
5.3.8.5 The MS shall support three way calling/call on hold functionality in both wireless and
cellular modes.
5.3.8.6 The MS should support three way calling/call on hold functionality with one leg in wireless
and the other in cellular mode.
5.3.9 Voice Quality and Codecs
5.3.9.1 Wireless mode voice quality shall be comparable to that obtained with good coverage
cellular, including delay and echo. This applies to both incoming and outgoing calls.
However, MS should aim to provide PSTN-equivalent voice quality when in wireless
mode. The FMCA recognises that certain aspects of this requirement may be met
through emerging Wi-Fi Alliance Voice over Wi-Fi certification. More details will follow in
5.3.9.2 The MS shall provide acoustic echo control that results in voice quality that is comparable
to that experienced with cellular networks.

st
31 August 2005
Page 26 of 49
t
5.3.9.3 The MS shall support the following codecs – G.711a LAW with PLC, G.729A, G.711
uLAW with PLC and the cellular codecs, subject to exact operator requirements.
Operators shall have the capability to enable/disable specific codecs and specify order of
preference.
5.3.9.4 The MS should support additional codec options as required by individual operators.
Operators shall have the capability to enable/disable specific codecs and specify order of
preference.
5.3.9.5 The MS shall support switching of codecs on call continuity in case of handover between
cellular and wireless modes.
5.3.9.6 The MS shall use an adaptive de-jitter buffer for IP packets.
5.3.9.7 If the MS is engaged on a voice call in wireless mode and the bandwidth and/or signal
strength needed to ensure a pre-defined voice quality drops below a defined threshold,
then the MS should be capable of evoking an adaptive codec mode and maintain the call
in wireless mode. The FMCA recognises that certain aspects of this requirement may be
met through emerging Wi-Fi Alliance Wireless Cellular Convergence (WCC) certification
5.3.9.8 If the MS receives an indication from the network that the bandwidth and/or signal
strength has fallen below a defined threshold, the MS shall be capable of initiating a
handover to cellular mode.
5.3.9.9 The MS should support the facility to provide an audible warning that wireless signal
strength is deteriorating prior to handover. This is to give users an early indication of a
potential network/tariff change.
5.3.9.10 The codecs in the MS should support VAD (Voice activity Detector) in wireless
and cellular modes. Where implemented, this shall be configurable (enabled/disabled) on
an Operator specific basis and shall be configurable independently for cellular and
wireless modes.
5.3.9.11 The codecs in the MS should support CNG (Comfort Noise Generation) in
wireless and cellular modes. This shall be configurable as enabled or disabled on an
Operator specific basis.
5.3.10 Mobility Requirements
5.3.10.1 The MS shall support inter AP transfers within an enterprise site or public Wi-Fi
hotspot. The FMCA recognises that certain aspects of this requirement may be met
through emerging Wi-Fi Alliance Wireless Cellular Convergence (WCC) and Voice over
Wi-Fi certifications. More details will follow in subsequent PRD releases.
5.3.10.2 The MS shall support voice call continuity and data session continuity in case of
AP to AP handover within an enterprise site or public Wi-Fi hotspot. The FMCA

st
31 August 2005
Page 27 of 49
t
Alliance Wireless Cellular Convergence (WCC) and Voice over Wi-Fi certifications. More
5.3.10.3 The user experience of the handover between APs should be seamless with no
loss of voice, no perceptible break and, where possible, a maximum voice break of no
more than 100ms. The FMCA recognises that certain aspects of this requirement may be
met through emerging Wi-Fi Alliance Wireless Cellular Convergence (WCC) and Voice
over Wi-Fi certifications. More details will follow in subsequent PRD releases.
5.3.10.4 The MS shall support voice call handover between cellular and wireless
networks, where the wireless network could be an enterprise, private home or public
hotspot network.
5.3.10.5 The user experience of the handover between wireless and cellular should be
seamless with no loss of voice (call continuity) and, where possible, a maximum voice
break of no more than 300ms.
5.3.10.6 When the MS switches between cellular and wireless networks, a data session
should not be dropped and any application that is running shall not be affected from a
user’s perspective. However, it is appreciated that the user may become aware of speed
changes and pauses.
5.3.10.7 For handover of a call from cellular to wireless, the MS shall be capable of
signalling to the core VoIP network using wireless while the cellular call is ongoing - if this
is required to support handover.
5.3.10.8 For handover of a call from wireless to cellular, the MS shall be capable of
signalling to the core VoIP network using cellular while the wireless call is ongoing - if this
is required to support handover.
5.3.10.9 The MS should support the capability to perform a cellular location update to the
cellular network upon handover, if required.
5.3.10.10 The MS shall rove to/from wireless and cellular networks, as required.
5.3.10.11 The MS shall rove between APs as required, when in wireless mode. The FMCA
Alliance Wireless Cellular Convergence (WCC) and Voice over Wi-Fi certifications. More
5.3.10.12 The maximum time to complete roving to/from a cellular network shall be no more
than 300ms. The FMCA recognises that certain aspects of this requirement may be met
through emerging Wi-Fi Alliance Wireless Cellular Convergence (WCC) and Voice over
Wi-Fi certifications. More details will follow in subsequent PRD releases.
5.3.10.13 The MS shall be capable of initiating a switch to cellular mode based on

measurement of downlink wireless signal strength. Measurement of wireless signal
strength alone is not sufficient: the MS should also take bit error rate and other relevant
factors into account.

st
31 August 2005
Page 28 of 49
t
5.3.10.14 The MS should support the capability to perform a cellular location update to the
cellular network upon roving, if required.
5.3.10.15 The MS shall use a hysteresis mechanism at the Wi-Fi level to prevent multiple
mode changes at the boundary of Wi-Fi coverage.
5.3.10.16 The MS shall support rove-in and rove-out timers to limit the number of
consecutive network changes (e.g. ‘ping-pong’ effect) and hence reduce network
signalling.
5.3.10.17 The MS shall support hand-in and hand-out timers to limit the number of
consecutive network changes (e.g. ‘ping-pong’ effect) and hence reduce network
signalling.
5.3.10.18 The MS shall send a presence update immediately after all rove-in/out and hand-
in/out mode changes to allow intelligent routing. This update should also be used to
ensure that the presence and IM servers are updated on the current MS network location.
Preferences for Presence implementation options (e.g. 3GPP, 3GPP2, OMA) shall be
defined in subsequent FMCA PRD releases, currently they are Operator specific.
5.3.11 Emergency Calls
5.3.11.1 The MS shall support configuration of the MS by the operator such that all
emergency calls are routed over the cellular network.
5.3.11.2 Emergency calls shall take precedence over the mode of the MS. This shall apply
even if the device is in wireless-only mode or wireless preferred mode and has its cellular
radio interface turned off, i.e. if the cellular radio is turned off and the MS is configured to
place emergency calls via the cellular network, the MS shall turn it on and proceed with
the emergency call via the cellular network.
5.3.11.3 The MS shall recognise all international emergency call codes programmed onto
handset/device and/or on the SIM or R-UIM (3GPP2).
5.3.11.4 The MS shall support at least 8 emergency call codes.
5.3.11.5 MS security mechanisms can be overridden for emergency calls, e.g. if the SIM
PIN has been enabled, the requirement to enter this PIN on power-up shall be waived for
emergency calls.
5.3.11.6 The total time taken for a reselection from wireless to cellular to facilitate an
emergency call shall not exceed seven seconds.
5.3.11.7 The MS shall support configuration by the operator such that emergency calls will
only be routed over wireless if no cellular signal is available.
5.3.11.8 The MS shall not hand over an emergency call from cellular to wireless, or vice
versa, unless the call would otherwise be dropped.

st
31 August 2005
Page 29 of 49
t
5.3.11.9 Emergency calls routed over wireless shall be given the highest priority marking
that is available and shall be appropriately routed.
5.3.11.10 The MS shall report the current AP information and GERAN/UTRAN or 3GPP2
Cell Information if available when making an emergency call in wireless mode.
5.3.11.11 The MS and Wi-Fi SIP network shall support the appropriate handling of deaf
service emergency call numbers. It should be noted that some operators may mandate
this requirement as a ‘shall’ due to local regulatory requirements.
5.3.12 Battery Life
5.3.12.1 As a minimum, the standard MS battery life shall last for 150 hours of standby
and five hours’ talk time when the MS switches between the two modes any number of
times.
5.3.12.2 The MS shall support a mechanism to dynamically adapt the power output to help
optimise battery life.
5.3.12.3 The MS shall support a power save mode.
5.3.12.4 A wireless connection shall not be dropped because the MS enters power-save
mode.
5.3.13 Wireless Physical Layer
5.3.13.1 The MS shall support the following transport options:

• IEEE 802.11b;
• IEEE 802.11g should be supported.
5.3.13.2 The MS shall have Wi-Fi Alliance certifications for layer 2 operation in IEEE
802.11b and IEEE 802.11g modes.
5.3.13.3 The MS should support for IEEE 802.11a, IEEE 802.11h, IEEE 802.11j and IEEE
802.11n as appropriate.
5.3.13.4 The MS should have Wi-Fi Alliance certifications for layer 2 operation in IEEE
802.11a and IEEE 802.11h.
5.3.13.5 Based on UMA recommendations, for IEEE 802.11b the minimum specification
for Transmit power at the antenna input for the MS shall be +17dBm (+3/-2 dBm). i The
Wi-Fi Alliance Wireless Cellular Convergence (WCC) certification. More details will follow
in subsequent PRD releases.
for Receive sensitivity for the MS shall be at least -87dBm (at 1Mbit/s) ii The FMCA

st
31 August 2005
Page 30 of 49
t
Alliance Wireless Cellular Convergence (WCC) certification. More details will follow in
for MS antenna gain shall be at least -10dBi iii . The FMCA recognises that certain aspects
of this requirement may be met through emerging Wi-Fi Alliance Wireless Cellular
Convergence (WCC) certification. More details will follow in subsequent PRD releases.
5.3.13.8 Based on UMA recommendations, when the MS is in cellular mode, the MS

should periodically scan for IEEE 802.11 coverage. The interval for scan is
implementation-specific, depending on power conservation strategies iv .
5.3.13.9 The MS should use SSID, security settings and RSSI, among other parameters,
to select which AP to join.
5.3.13.10 The MS shall be capable of connecting to APs which are broadcasting their SSID
details (as per Wi-Fi Alliance IEEE 802.11abg certifications) and APs that are not
broadcasting SSID details.
5.3.13.11 Based on UMA recommendations, the MS should be able to (internally) measure

RSSI values between -45 dBm and -86 dBm with a step size of 1dB. An Inter-AP
‘roaming threshold’ should be set such that there is reasonable opportunity to discover
other APs when the signal from the current AP drops (before the MS is forced to switch to
cellular mode) v .
5.3.13.12 Based on UMA recommendations, The MS IEEE 802.11 driver shall keep upper
layers unaffected by change of AP (provided the IP address does not change). vi
Communication interruption due to change of AP (in the same subnet) shall be kept
below 100 ms.
5.3.13.13 The MS shall support simultaneous operation of Bluetooth accessories (e.g.

headset) and Wi-Fi operation.
5.3.13.14 Based on UMA recommendations, The MS shall use power-save/sleep mode as

follows vii :
• when in cellular mode, the MS shall periodically scan for IEEE 802.11 coverage,
with the frequency of the scan being Operator implementation specific,
• when in wireless mode, but not on an active call, the MS shall use power-save mode
with an implementation-specific sleep interval, e.g. waking up periodically to check
for incoming traffic, maintain synchronisation and make RSSI measurements,
• When in wireless mode and on an active call, the MS may use power-save mode.

st
31 August 2005
Page 31 of 49
t
5.3.13.15 The MS should be compliant with emerging Wi-Fi Alliance WMM-Power Saving
Certifications.
5.3.13.16 Provision should be made for mitigating interference from other devices operating
in the same wireless spectrum.
5.3.14 Wireless Security
5.3.14.1 The MS shall support WEP (RC4) and WPA (TKIP) at the minimum.
5.3.14.2 The MS should support IEEE 802.11i / WPA 2.
5.3.14.3 The MS should support IEEE 802.1x.
5.3.14.4 The MS should support one or more Operator specified upper layer
authentication protocols, e.g. HTTP, HTTPS, SSL/RADIUS, EAP TLS, PEAP, EAP-FAST,
XML mini-browser in particular for public hotspot scenarios.
5.3.14.5 The MS shall support open access, i.e. no WEP, no WPA, no WPA 2. This option
shall be configurable (enabled/disabled) by the Operator.
5.3.14.6 The MS shall be compliant with Wi-Fi Alliance WPA and WPA 2 certifications.
5.3.14.7 The MS should be compliant with Wi-Fi Alliance Extended EAP certifications.
5.3.14.8 Pre-shared keys, or derivative of the key, shall be stored on the MS in a way that
means it cannot be read from the device, e.g. the key may be encrypted.
5.3.14.9 The WPA, WPA 2 pre-shared key for authentication should be at least 20
characters, pseudo-random and consisting of digits 0-9 and characters a-z.
5.3.14.10 The MS shall provide a user friendly mechanism for entry of the Wi-Fi pre-shared
key onto the MS, e.g. the key should be user-entered on the MS in groups of four or five
characters.
5.3.14.11 MS should provide a user friendly mechanism for entry of scripted based login
details onto the MS for use with public hotspots. Scripting requirements to be specified by
operator.
5.3.14.12 When an MS successfully associates and authenticates with an AP for the first
time, it shall store the association/authentication details as a wireless profile within MS. The MS
wireless profile should be able to store a number of key details, e.g. MAC address, IP address,
QoS/DSCP settings, AP details, SSID, security settings, channel, etc.
5.3.14.13 After the MS has successfully attached the first time, for all types of AP, the MS
to AP Authentication on connection shall be seamless and shall not require any keystroke
entry on the MS to attach to the service.
5.3.15 Wireless QoS


st
31 August 2005
Page 32 of 49
t
5.3.15.1 The Wi-Fi air interface shall be optimised for voice, i.e. voice delay shall be
minimised and the MS should internally prioritise voice packets ahead of any other data
packets that are to be transmitted.
5.3.15.2 The MS shall prioritise voice over data if it is supporting a voice call and a data
session over the Wi-Fi air interface at the same time.
5.3.15.3 The MS shall support the IEEE 802.11e EDCA to allow prioritised access for
voice packets to the medium.
5.3.15.4 The MS shall set the IEEE 802.11e EDCA access categories - voice, video, best
effort, background - based on the traffic type, e.g. voice, data, signalling.
5.3.15.5 The MS shall be certified by the Wi-Fi Alliance for compliance to WMM.
5.3.15.6 MS functionality should progress from WMM certification to full IEEE 802.11e
capability and at this stage should be certified by the Wi-Fi Alliance for compliance to
their emerging WMM-SA certifications.
5.3.16 Wireless Profile
5.3.16.1 The MS shall have the capability to maintain multiple wireless profiles with each
profile identified based on the SSID. The user shall have the ability to label the wireless
profile; the default shall be the SSID. A wireless profile is a set of service parameters that
enables a Wi-Fi device to associate with and access a Wi-Fi network.
5.3.16.2 The MS shall be capable of storing a minimum of 32 wireless

profiles/associations and differentiate between them based on Wi-Fi parameters such as
SSID and MAC address. Operators shall have the ability to restrict the maximum number
of WLAN associations. MS shall support user configurable options for new profiles when
the MS maximum number of wireless associations limit is reached. For example, whether
to automatically delete the least used profile, or to alert the user that an existing profile
will need to be deleted before the new profile can be added.
5.3.16.3 The MS shall attempt to associate to Wi-Fi networks in the order determined by
the wireless profile priorities.
5.3.16.4 When an MS successfully associates and authenticates with an AP for the first
time, it shall store the association/authentication details as a user profile or thumbprint
within MS.
5.3.16.5 The MS shall have a simple user interface to allow the user to configure wireless
profiles, e.g. addition, deletion etc. These profiles should ideally be able to be modified
over the air.
5.3.16.6 For 3GPP2 networks, MS should provide support for multiple profile slot
capability in support of Mobile IP and Simple IP services. Wi-Fi profiles should be in
addition to cellular profiles.

st
31 August 2005
Page 33 of 49
t
5.3.17 User Interface
5.3.17.1 The MS shall support a common user interface for both modes, which shall be
simple and consistent. It is noted that there may be minor differences, e.g. display
indications.
5.3.17.2 User action to make and receive calls shall be the same, regardless of mode.
5.3.17.3 The MS shall provide a visible indication of mode i.e. wireless or cellular mode.
The indication should change automatically when the mode changes, this feature shall be
operator configurable. The FMCA recognises that certain aspects of this requirement
may be met through emerging Wi-Fi Alliance Wireless Cellular Convergence (WCC)
certification. More details will follow in subsequent PRD releases.
5.3.17.4 The MS shall provide a user indication of AP connectivity.
5.3.17.5 The MS shall show an indication of SIP registration, if in wireless mode.
5.3.17.6 The MS shall indicate which access network is being used for any incoming or
outgoing call, if this is not implicit from the mode indication.
5.3.17.7 The MS shall be able to provide either consistent or different ring tones and
volumes based upon mode of operation. Selection shall be Operator/user configurable.
5.3.17.8 The MS shall provide an indication of both wireless signal strength and cellular
signal strength. The FMCA recognises that certain aspects of this requirement may be
met through emerging Wi-Fi Alliance Wireless Cellular Convergence (WCC) certification.
5.3.17.9 The MS should support the facility to provide an audible warning that wireless
signal strength is deteriorating prior to handover. This is to give users an early indication
of a potential network/tariff change. This option should be user/Operator on/off
configurable.
5.3.17.10 The MS user shall be able to configure the MS to be in any of the following four
modes:
– wireless-only – the service can only be accessed when in wireless coverage;
– wireless-preferred – the MS shall register to the SIP server when in wireless

coverage and SIP will be the default means of making outgoing connections. The
Operator will define whether the cellular radio interface remains simultaneously
active or not in this mode;
– cellular-preferred – the MS shall provide service via the wide-area cellular

network when in coverage. When there is no cellular coverage, the MS shall
register and provide service via the wireless network, if available. Note that the
MS shall not automatically switch mode if this will terminate a voice call in
progress;

st
31 August 2005
Page 34 of 49
t
– cellular-only – the service can only be accessed via a wide-area cellular network.

st
31 August 2005
Page 35 of 49
t
5.3.17.11 An audible indication should be provided to the user when the MS performs a
handover to/from the cellular network. The actual indication shall be different depending
on the direction of the mode change.
5.3.17.12 Use of the audible indication on handover shall be both user and Operator
configurable (on/off).
5.3.18 Number Management
5.3.18.1 The MS shall use the same number management facilities, e.g. address book,
dialling capability, call history, etc. for both modes.
5.3.18.2 The MS should support short code dialling and translation of calls prefixed with ‘+’
for international country code in both modes.
5.3.18.3 Caller display information for incoming calls in both wireless and cellular modes
shall be supported.
5.3.18.4 In wireless mode, the MS should support the option for both the SIP user ID and
SIP Display Name to be presented on the MS display as part of the caller display
information for incoming calls.
5.3.18.5 In wireless and cellular modes, the MS shall support the ability for customers to
withhold the calling line identity on a per call or full time basis using the appropriate
prefix/short code in use by the network Operator. The prefix/short code to block the
calling line identity shall be the same in wireless and cellular modes (as per local
regulations).
5.3.19 Data Connectivity
5.3.19.1 The MS should support data connectivity over both wireless and cellular
networks. The FMCA recognises that certain aspects of this requirement may be met
through emerging Wi-Fi Alliance Wireless Cellular Convergence (WCC) certification.
5.3.19.2 The MS should support data and voice connectivity simultaneously in both
wireless and cellular modes. The MS shall be able to multitask voice and data sessions.
For example, when engaged on a voice call (in either mode), the user may access
directories so the call may be transferred and the ability for a user to access live email at
the same time as a voice call.
5.3.19.3 The MS shall support data rates when in wireless mode that are at least as high
as those supported in cellular mode and should take advantage of the higher data rates
available from the wireless network.
5.3.19.4 When the MS transfers between APs on an enterprise site, hotspot or in a home,
data connectivity should not be dropped and an application that is running shall not be
affected from a user’s perspective.

st
31 August 2005
Page 36 of 49
t
5.3.19.5 When the user leaves wireless coverage and enters cellular coverage, data
connectivity should be maintained and an application that is running shall not be affected
from a user’s perspective. This requirement is dependent on similar network resources
being available.
5.3.19.6 When the user leaves cellular coverage and enters wireless coverage, data
connectivity shall be maintained and an application that is running shall not be affected
from a user’s perspective.
5.3.19.7 The MS should support CSD calls on the wireless network. It should be noted
that due to local regulatory requirements or existing services some Operators may
mandate that the MS shall support CSD calls on the wireless network.
5.3.19.8 A CSD call should not be dropped due to inter AP transfer or handover.
5.3.20 General Security
5.3.20.1 The MS shall not be vulnerable to unauthorised access to data or services on the
MS.
5.3.20.2 Wi-Fi SIP services shall not be vulnerable to unauthorised access to data or
services on the device, e.g. ‘man-in-the-middle’ and bogus server attacks.
5.3.20.3 The MS shall support encryption over the air interface to the AP that is at least as
good as GSM / IS41 ciphering.
5.3.20.4 The MS should implement WPA 2 and/or IPsec. Options to be configurable

(enable/disable) by operator. This requirement will be clarified and expanded on in
5.3.20.5 The MS shall be flexible to operator security requirements, e.g. ability to secure
one or both – signalling and media traffic.
5.3.20.6 The MS shall support a security solution which provides mutual authentication of
MS and wireless network.
5.3.20.7 High-end devices should be secured such that:

i) following entry of the PIN, the voice call user interface shall be freely available;
ii) all other applications shall be accessible only after entering a second level of
authentication. Authentication options to be configurable.
5.3.20.8 The MS shall provide VPN support.
5.3.20.9 The MS should have the capability to support a personal firewall and anti-virus
software. The MS should also support remote management capabilities for personal
firewalls and antivirus software, where used. The MS firewall shall protect all external
interfaces - wireless, Bluetooth, etc. on the MS.

st
31 August 2005
Page 37 of 49
t
5.3.20.10 The MS shall support cellular authentication and cellular ciphering when in
cellular mode.
5.3.20.11 The MS shall have a valid IMEI/MEID that cannot be manipulated.
5.3.20.12 The MS shall ensure that security keys used to encrypt communications have a
cryptographic key strength of at least 128bits.
5.3.20.13 Where pre-shared keys are used to secure communications between the MS and
AP, they shall not be transmitted insecurely over the air interface.
5.3.20.14 Where used, pre-shared keys shall not be exchanged but information
derived/computed from them may be exchanged.
5.3.20.15 Protection shall include integrity protection and encryption of the communications
data. The protection mechanism shall support the secure traversal of UDP.
5.3.20.16 HMAC MD5 or equivalent shall be used for ensuring message integrity of set-up
and secured communications messages.
5.3.20.17 Signalling information shall be appropriately secured to protect integrity.
5.3.20.18 MS keys and passwords shall be secure and not uploadable or retrievable.
5.3.21 IP QoS
5.3.21.1 For 3GPP2 – MS shall support QoS profiles as per IS-835.4.
5.3.21.2 The MS shall support setting of DiffServ code points as appropriate.
5.3.21.3 The MS shall be capable of prioritising traffic based on received DiffServ code
points.
5.3.21.4 The MS shall provide the ability to separately mark voice and signalling traffic
(e.g. using DiffServ), in a manner which cannot be altered by the user.
5.3.21.5 The MS shall be capable of segregating voice and data traffic in a manner which
the user cannot change.
5.3.21.6 The MS shall set the DSCP/ToS bits in the IP header - this refers to the IP header
outside the IPsec tunnel - in accordance with RFC 2474. One implication of this is that
the DSCP/ToS bits from the IP header inside the IPsec tunnel shall be copied to the outer
IP header.
5.3.21.7 The MS should support the option to internally prioritise voice packets ahead of
any other data packets that are to be transmitted.
5.3.22 Diagnostics, OTA & Remote Management

st
31 August 2005
Page 38 of 49
t
5.3.22.1 The 3GPP MS shall support OMA device management capabilities. 3GPP2 MS
shall support TIA-1010.
5.3.22.2 MS shall support necessary diagnostics, error codes and remote management
capabilities. Example 1: a diagnostic log of at least the last 20 events (e.g. SIP signalling
messages). Example 2: for failed SIP calls/registration attempts, the MS should support
the option to display the relevant numeric SIP failure code on the MS display, along with
a text explanation. This failure information should be capable of being suppressed after a
period of configurable interval, but should remain available to the user via a status menu
option.
5.3.22.3 MS shall support local diagnostics for both wireless and cellular connectivity, e.g.
success/failure of Wi-Fi connection, DNS look-up, secure gateway connection, tunnel set-
up, SIP registration, etc.
5.3.22.4 MS should support remote diagnostics (when connected and where authorised
by the user) and file upload for both modes. The MS should support upload to customer
service centre of a single file containing complete MS configuration data. Any security
keys and passwords should be excluded from this file upload.
5.3.23 Accessories
5.3.23.1 A comprehensive range of accessories for mid-tier/high-tier handsets should be

available. Accessories should include: fully featured car kit, Bluetooth headset, spare
standard and high capacity batteries, charger for handset/spare battery. Entry level
handsets shall have, as a minimum, a corded earpiece and microphone, car charger and
holder. Desktop docking station to include: corded handset, display, charger, keypad,
hands-free.
5.3.23.2 The use of Wi-Fi shall not prevent the simultaneous use of a Bluetooth (at least
v1.2) port on the MS.
5.3.24 Regulations
5.3.24.1 The MS shall meet in-country/region mandatory cellular and Wi-Fi Health and
Safety requirements.
5.3.24.2 The MS shall meet relevant in-country/region requirements, e.g. CE marking and
the EC WEEE directive
5.3.24.3 The MS shall meet the ICNIRP guidelines
5.3.24.4 The MS shall support LAES encryption aspects.
5.3.24.5 The MS shall support local regulation for TTY in wireless and cellular modes.
5.4 AP Requirements

st
31 August 2005
Page 39 of 49
t
It is recognised that there will be various forms of APs/wireless gateways to address different
market segments, e.g.:
• Wi-Fi enabled APs and/or gateways for consumer services;
• low-end APs for SOHO services;
• medium-end APs for Enterprise and Corporate services;
• high-end APs for Enterprise and Corporate services;
• public Wi-Fi hotspot APs;
• temporary portable APs, e.g. USB dongles for laptops.
The purpose of this section is to define Wi-Fi SIP AP product requirements.

st
31 August 2005
Page 40 of 49
t
5.4.1 Generic AP Requirements
5.4.1.1 APs shall be deployable in existing wireless corporate networks, public Wi-Fi hotspots
and home networks without disruption to their existing services. The FMCA recognises
that certain aspects of this requirement may be met through emerging Wi-Fi Alliance
Public and Managed Access certification. More details will follow in subsequent PRD
releases.
5.4.1.2 APs should have mechanisms to support ‘Guest’ services i.e. allow visiting users to gain
access to Wi-Fi SIP voice services and the internet via their connections.
Corporate/Enterprise APs shall have additional guest features to limit access, e.g. restrict
access to internet only. The FMCA recognises that certain aspects of this requirement
may be met through emerging Wi-Fi Alliance Public and Managed Access certification.
5.4.1.3 APs should work with the core network to support functionality to restrict the maximum
number of permitted wireless voice calls to a predetermined limit, so as not to overload
fixed backhaul connections. Where an AP delivers voice and data, this should include the
capability to partition bandwidth on a static or dynamic basis between real time and non-
real time traffic. The FMCA recognises that certain aspects of this requirement may be
met through emerging Wi-Fi Alliance Voice over Wi-Fi certification. More details will follow
5.4.1.4 APs should work with the core network to support functionality to alert the end user when
there is insufficient network capacity available to facilitate their call.
5.4.1.5 APs should have the option to support power over Ethernet.
5.4.1.6 Range of AP enclosures should be available to support different operational

environments, e.g. ruggedised units for outside APs and optional cable/DSL connections
for consumer APs.
5.4.1.7 APs shall have functionality to allow their (default) transmit power levels to be manually
configured through a management interface.
5.4.1.8 The AP shall at the minimum support conformance to IEEE 802.11b, IEEE 802.11g.
5.4.1.9 The AP should support conformance to IEEE 802.11a, IEEE 802.11h, IEEE 802.11j and
IEEE 802.11n as per regional operator requirements.
5.4.1.10 The AP shall have Wi-Fi Alliance certifications for layer 2 operation in IEEE
802.11b and IEEE 802.11g modes (if these modes are provided by the AP) and shall be
compliant with other IEE 802.11b/g systems.
5.4.1.11 The AP should have Wi-Fi Alliance certifications for layer 2 operation in IEEE
802.11a and IEEE 802.11h modes (if these modes are provided by the AP) and shall be
and be compliant with other systems operating in these modes.

st
31 August 2005
Page 41 of 49
t
5.4.1.12 Provision should be made for mitigating interference with other devices operating
in the same wireless spectrum
5.4.1.13 Based on UMA recommendations, The minimum specification for Access Point
antenna gain should be at least -0dBi viii .The FMCA recognises that certain aspects of
this requirement may be met through emerging Wi-Fi Alliance Wireless Cellular
Convergence (WCC) certification. More details will follow in subsequent PRD releases.
for transmit power at the antenna input for the AP shall be +17dBm (+3/-2 dBm) ix . The
Wi-Fi Alliance Wireless Cellular Convergence (WCC) certification. More details will follow
for receive sensitivity for the AP shall be at least -87dBm (at 1Mbit/s) x The FMCA
Alliance Wireless Cellular Convergence (WCC) certification. More details will follow in
5.4.1.16 APs should have the option to support detachable antennas.
5.4.1.17 The Wi-Fi AP should support separate transmit and receive antenna diversity on
a client by client basis.
5.4.1.18 The AP should transmit periodic beacons at least every 100 ms.
5.4.1.19 The Wi-Fi AP should support WDS to enable support for wireless repeaters. It
should be possible to enable security on the repeater using a ‘single touch mechanism’.
5.4.1.20 The Wi-Fi AP shall support the Wi-Fi frequency channels available in the specific
country/region.
5.4.1.21 The Wi-Fi AP shall support at least 15 simultaneous wireless users (including Wi-
Fi SIP handsets and other Wi-Fi devices).
5.4.1.22 Based on UMA recommendations, the Wi-Fi AP should support IAPP or similar
vendor specific inter-AP protocol to speed up context transfer for a roaming MS xi .
5.4.1.23 Based on UMA recommendations, the AP shall support MS that want to use
power save mode. Specifically, it should recognise the Power Management bit in the
frame header and, if an MS indicates it is going to enter PS-mode, the AP should buffer
any incoming traffic for that MS and indicate that via a Traffic Indication Map (TIM) or
DTIM. The AP should support Power Save Polling by the MS. xii
5.4.1.24 The AP should be compliant with emerging Wi-Fi Alliance WMM-Power Saving
Certifications.
5.4.1.25 The AP shall support a minimum of two SSIDs.


st
31 August 2005
Page 42 of 49
t
5.4.1.26 The AP should support at least eight SSIDs.
5.4.1.27 The AP shall support the capability of broadcasting SSIDs on a per SSID basis.
5.4.1.28 The AP shall support the mapping of individual SSID to specific VLAN tags,
PPPoE/PPPoA sessions and DiffServ settings as required by operators.
5.4.1.29 The AP should support bandwidth management on a per SSID basis.
5.4.1.30 The Wi-Fi AP or WLAN switches (in the scenario where a number of AP are
managed by a WLAN switch) shall support storing a number of Wi-Fi UMA profiles in their
non volatile memory.
5.4.1.31 The AP shall support WEP (RC4) and WPA (TKIP) at the minimum.
5.4.1.32 The AP should support IEEE 802.11i / WPA 2.
5.4.1.33 The AP should support IEEE 802.1x.
5.4.1.34 The AP should support one or more operator specified upper layer authentication
protocols, e.g. HTTP, HTTPS, SSL/RADIUS, EAP-TLS, PEAP, EAP-FAST, XML mini-
browser.
5.4.1.35 The AP shall support open access, i.e. no WEP, no WPA. This support shall be
configurable (enabled/disabled) by the Operator.
5.4.1.36 The AP shall be compliant with Wi-Fi Alliance WPA and WPA 2 certifications.
5.4.1.37 The AP should be compliant with Wi-Fi Alliance Extended EAP certifications.
5.4.1.38 The AP shall support the IEEE 802.11e EDCA to allow prioritised access for
voice packets to the medium.
5.4.1.39 The AP shall set the IEEE 802.11e EDCA access categories - voice, video, best
effort, background - based on the traffic type, e.g. voice, data, signalling.
5.4.1.40 The AP shall be certified by the Wi-Fi Alliance for compliance to WMM.
5.4.1.41 AP functionality should progress from WMM certification to full IEEE 802.11e
capability and at this stage should be certified by the Wi-Fi Alliance for compliance to
their emerging WMM-SA certifications.
5.4.1.42 The Wi-Fi AP shall discern voice packets, e.g. using IEEE 802.1p tags or IP
TOS/DS markings, to internally prioritise voice packets ahead of any other data packets
that are to be transmitted on the wireless network. The AP shall support IEEE 802.11e
EDCA (or WME) to allow prioritised access for voice packets to the medium. Mapping to
SSID to be operator defined.

st
31 August 2005
Page 43 of 49
t
5.4.1.43 The Wi-Fi AP shall support various QoS options on both wireless and WAN/LAN
interfaces to appropriately identify, tag and prioritise voice traffic.
5.4.1.44 The Wi-Fi AP shall be capable of supporting a minimum of three simultaneous

Wi-Fi SIP calls and at least five associated Wi-Fi SIP users. This value should be
configurable by the user or by remote management. The minimum number of calls will be
operator-dependent, given varying backhaul capacity limitations.
5.4.1.45 The Wi-Fi AP shall support the ability to restrict the number of users that can
simultaneously connect to the Wi-Fi AP. This value shall be configurable by the service
provider and/or the end user.
5.4.1.46 The Wi-Fi AP shall support the ability to restrict the maximum number of
associations per AP. This value shall be configurable by the service provider and/or the
end user.
5.4.1.47 The Wi-Fi AP point shall support NAT, DHCP client and DHCP server
functionality.
5.4.1.48 The Wi-Fi AP should support remote management capabilities as covered by the
DSL Forum TR69 extensions for LAN connected devices e.g. WT111, WT104, WT98.
Where implemented there shall be the operator option to disable TR69 functionality.
5.4.1.49 End-user APs should support multiple VLANs.
5.4.1.50 End-user APs should support multiple WAN ( backhaul ) VLANs e.g. for data and
voice.
5.4.1.51 The AP should support multiple PPPoE clients and multiple simultaneous WAN
PPPoE sessions for the purpose of SSID mapping.
5.4.1.52 The AP should support a single PPPoE client.
5.4.1.53 The AP should support the mapping of SSID to WAN (backhaul ) VLAN tags and
WAN PPPoE/PPPoA sessions as required by operators.
5.4.1.54 AP option should include support for a Wi-Fi SIP AP with an Ethernet interface.
5.4.1.55 APs shall support access control lists to restrict access to known MAC
addresses. These lists shall be configurable via the management interface.
5.4.1.56 The AP shall support access lists to enable the device to be locked down using
IP address and protocol to the user’s requirements.
5.4.1.57 The AP shall support IPsec traffic.
5.4.1.58 The AP shall support Secure Sockets Layer (SSL) traffic.

st
31 August 2005
Page 44 of 49
t
5.4.1.59 The Wi-Fi AP or WLAN switches (in the scenario where a number of AP are
managed by a WLAN switch) shall support storing a number of Wi-Fi UMA profiles in their
non-volatile memory.
5.4.1.60 End-user APs should support multiple VLANs and packet tagging e.g. for data
and voice.
5.4.1.61 AP should support SIP-ALG and B2BUA as required by individual operators.
5.4.1.62 The AP should support static IP routing to a specific destination based on source
SSID and/or source/destination IP address.
5.4.2 Gateway Requirements
5.4.2.1 CPE options should include a gateway solution, e.g. an integrated AP/DSL modem.
5.4.2.2 AP should support for SIP client and a terminal adapter.
5.4.3 Enterprise AP Requirements
5.4.3.1 Enterprise AP shall support power over Ethernet support – IEEE 802.3af.
5.4.3.2 APs should support the option for authentication by reference to RADIUS servers.
5.4.3.3 APs should have support for IEEE 802.1x in RADIUS as specified in RFC3580.
5.4.3.4 APs should support the EAP extensions to the RADIUS protocol as specified in
RFC3579.
5.4.3.5 APs should support downloadable access control lists from a central AAA server based
on the user’s authentication profile.
5.4.3.6 APs should have functionality that allows them to generate accounting information for
billing utilisation of the AP resources by individual users.
5.4.3.7 APs should support download of ‘static’ QoS policies via the remote management
system.
5.4.3.8 APs shall have functionality to assign IP addresses from a locally configured pool.
5.4.3.9 APs shall have the functionality to assign IP addresses via reference to a (remote) DHCP
server.
5.4.3.10 APs should support static, RIP and RIPv2 and OSPF routing protocols.
5.4.3.11 APs shall support a DNS relay.
5.4.3.12 APs should support NAT and NAPT.

st
31 August 2005
Page 45 of 49
t
5.4.3.13 APs should support Foreign Agent functionality as per RFC3344.
5.4.3.14 APs should, if required, support built-in firewall capabilities that are certified by
ICSA. Firewall support should cover the following functions:
stateful packet inspection;
IP Source address filtering;
IP destination address filtering;
IP Protocol filtering;
Port filtering;
DMZ;
ALGs;
Port Forwarding;
Denial of Service protection;
Firewall rule partitioning per VLAN/IP subnet.
5.4.3.15 Enterprise solution APs should have the option to support intrusion detection
functions.
5.4.4 Public Wi-Fi Hotspot AP Requirements
5.4.4.1 Public Wi-Fi Hotspots should support one or more of the following options to facilitate Wi-
Fi SIP MS association / authentication. Selection of required approach will be operator
specific.
• a simplified version of existing SSL/RADIUS authentication using just a ‘single
shot’ HTTPS get command;
• trusted ‘walled gardens’ for Wi-Fi UMA traffic, bypassing it straight through to the
UNC. The UNC would then be responsible for authenticating the end user and all
billing and audit functions;
• IEEE 802.1x (shared key authentication and open authentication) and EAP, e.g.
EAP-SIM and EAP-AKA;
• APs shall support IEEE 802.3af.

st
31 August 2005
Page 46 of 49
t
5.5 Network Requirements
5.5.1 The Wi-Fi SIP network shall provide the correct location of the user to the correct (PSAP).
Preferred options for implementing this will be defined in PRD release 2.
5.5.2 The end user shall be reachable at the same directory number whether attached to
wireless or cellular network subject to operator enable/disable capability.
5.5.3 A connection attempt to/from the MS shall be refused if the personal firewall is not
running or not correctly configured. This functionality shall be operator configurable.
5.5.4 The Wi-Fi SIP service shall support the capability for operators to disable MS services,
for example by denying access to SIP servers.
5.5.5 For 3GPP2 networks, the ability to tunnel the Wi-Fi session back to the operator network
should be based on Mobile IP. The MS should support protocols such as Mobile IP (as
per IS-835), encompassing co-located Care-Of-Address mode, IPsec releated protocols
and protocols related to negotiating NAT traversal such as UDP encapsulation schemes
and IKE within NAT environments.
5.6 Corporate/Enterprise Connectivity
Requirements in this section cover both MS and AP.
5.6.1 Wi-Fi SIP services shall support enterprise connectivity through integration with a wide
range of existing PBX/LAN infrastructure and secure access to, and protection of,
corporate data in all modes.
5.6.2 Wi-Fi SIP services and solutions shall support integration with existing enterprise
telephony TDM or IP based PBXs and Centrex services.
5.6.3 Wi-Fi SIP services and solutions shall support integration with existing enterprise
networks – IP LANs, IP VPNs, etc.
5.6.4 The Wi-Fi SIP MS shall be able to place/receive calls to/from any subscriber number
within a corporate’s telephony network. The call shall be placed/received using
appropriate Signalling Gateway/Converters and Media Gateways.
5.6.5 Wi-Fi SIP services and solutions shall support ‘local switching’ i.e. when the voice call
source and destination are on the same geographic site within the corporate network, the
voice call (media path) should then be routed entirely within the local site.
5.6.6 Wi-Fi SIP corporate/enterprise solutions and services shall support interworking with
common (supplementary) services. For example:
– three-party calls
– call screening (Manager/Secretary function)
– call transfer
– call re-direction

st
31 August 2005
Page 47 of 49
t
– call waiting and ‘ring-back when free’

– use of short-codes
– caller display if supported by existing corporate voice network.
5.6.7 It shall be possible to restrict Wi-Fi SIP MS that can connect to enterprise/corporate
networks to only those provisioned by the corporate/enterprise. Management of this
provisioning shall be performed by the corporate/enterprise.
5.6.8 Corporates shall be able to manage the provision, suspension or removal of individual or
groups of Wi-Fi SIP devices, and manage user access in order to specify individual users
that are able to connect via:
– public Wi-Fi hotspots

– cellular networks
– corporate networks
– via teleworker access
– temporary portable APs, e.g. USB dongles for laptops.

st
31 August 2005
Page 48 of 49
t
6 Appendix 1 – Summary of UMA Specification References
The following list highlights requirements which are based on UMA Stage 2 recommendations. It
is acknowledged that this material may be copyright of the participating partners of UMA
Technology.
i
UMA Architecture (Stage 2) R1.0.4 – Appendix A.1.2 802.11
ii
iii
iv
UMA Architecture (Stage 2) R1.0.4 – Appendix B1.1 Recommended 802.11 MS Capabilities
v
vi
vii
viii
ix
x
xi
UMA Architecture (Stage 2) R1.0.4 – Appendix B.1.2 Recommended 802.11 AP Capabilities
xii
UMA Architecture (Stage 2) R1.0.4 – Appendix B.1.2 Recommended 802.11 AP Capabilities
END OF REPORT
Report Author
FMCA (rodrigo.donazzolo@thefmca.com)
Document History
Convergence Services using SIP over Wi-Fi Release 1 31 August 2005.

st
31 August 2005
Page 49 of 49

Convergence Services Using SIP Over Wi-Fi: Release 1 - 31 August 2005

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Convergence Services Using SIP Over Wi-Fi: Release 1 - 31 August 2005

Uploaded by

Copyright:

Available Formats

Convergence Services using

SIP over Wi-Fi

Release 1 – 31st August 2005

FMCA Product Requirement

© 2005, FMCA, All Rights Reserved.

4 Convergence Services Using SIP Over Wi-Fi 15

4.1 What Are Convergence Services Using SIP Over Wi-Fi? 15

4.2 Wi-Fi SIP PRD 16

5.1 General End-to-End Aspects 18

5.2 SIP Functionality 19

5.3 Mobile Station 20

5.5 Network Requirements 47

5.6 Corporate/Enterprise Connectivity 47

6 Appendix 1 – Summary of UMA Specification References 49

© 2005, FMCA, All Rights Reserved.

Bluetooth Special Interest Group:

© 2005, FMCA, All Rights Reserved.

* As of 31st August 2005.

© 2005, FMCA, All Rights Reserved.

2G Second Generation cellular mobile technology/systems.

2.5G Enhanced 2G cellular technologies, such as higher speed

© 2005, FMCA, All Rights Reserved.

Coverage Zone of coverage created by one or multiple wireless

© 2005, FMCA, All Rights Reserved.

Presence services Service capabilities based on a user’s presence, e.g.

Seamless Seamless is defined as there being no perceptible break in

© 2005, FMCA, All Rights Reserved.

Wireless For the purpose of this paper, wireless enabled devices or

© 2005, FMCA, All Rights Reserved.

This document uses the following acronyms:

© 2005, FMCA, All Rights Reserved.

DSCP/ToS Differentiated Services Code Point / Type of Service

© 2005, FMCA, All Rights Reserved.

ISIM IM Subscriber Identity Module

© 2005, FMCA, All Rights Reserved.

RIP Routing Information Protocol

© 2005, FMCA, All Rights Reserved.

WLAN Wireless Local Area Network

© 2005, FMCA, All Rights Reserved.

4 Convergence Services Using SIP Over Wi-Fi

4.1 What Are Convergence Services Using SIP Over Wi-Fi?

© 2005, FMCA, All Rights Reserved.

Figure 1 – Initial Wi-Fi SIP Concept

4.2 Wi-Fi SIP PRD

© 2005, FMCA, All Rights Reserved.

© 2005, FMCA, All Rights Reserved.

5.1 General End-to-End Aspects

© 2005, FMCA, All Rights Reserved.

5.2 SIP Functionality

© 2005, FMCA, All Rights Reserved.

5.3 Mobile Station

5.3.3 Connection Establishment

© 2005, FMCA, All Rights Reserved.

5.3.3.3 The MS shall automatically attach to a cellular network if it is in cellular-only-mode.

5.3.4 Connection to Wi-Fi AP

5.3.4.6 The MS shall be capable of associating to an AP which is broadcasting its SSID.

5.3.4.10 The MS shall be capable of storing a minimum of 32 wireless

© 2005, FMCA, All Rights Reserved.

5.3.4.13 The MS shall support the option of connecting to a pre-configured SSID, if

5.3.4.16 If a MS successfully associates to an AP but fails to register successfully to the

5.3.5 Connection to Network

© 2005, FMCA, All Rights Reserved.