Fixed-Mobile Convergence – FMC

UMA-based dual-mode WiFi/cellular:
Positives:
· Is engineered from the ground up around "seamless" handover. This is both a positive and a negative.
· Phones and semiconductors becoming available
· Standardised & now adopted by 3GPP as GAN
· Reasonable range of infrastructure providers
· Relatively cheap to deploy at first
· Possible usage cases for MVNOs
· Good, cellular-grade security and authentication mechanisms. UMA may well be reincarnated as a security technology. Good way for operators to learn about FMC customer experience, marketing proposition, support etc.

Limitations:
· Limited and expensive range of handsets
· Not suitable for large enterprise
· Does not currently support 3G
· In practical deployment, requires operator-provided gateway
· Could be blocked by broadband operator in the network
· Potential for huge customer service & support costs
· Assumes that usage over WLAN should give the same "user experience" as over cellular - ie not intended for "bearer-aware" applicationsDoes not work well with multiple WLAN access points (no standards for connection management software)


IMS / VCC-based dual-mode Wi-Fi/cellular (VCC = voice call continuity):
Positives:
· Based around a clear vision of future IMS-based operator networks
· Significant levels of enthusiasm from major operators
· Exploits growing use of SIP in both handsets and networks
· Wide range of equipment vendors supplying pre-standard convergence solutions
· Some operators already skipping UMA and going straight to pre-IMS dual-mode
· May be flexible enough to allow handset applications to be "bearer aware" Will do "seamless" handover

Limitations:
· No "full IMS" handsets available yet; standardisation will take some time.
· VCC standards incomplete
· Not obvious how interoperability with enterprise IP-PBX systems will work. Mobile IP centrex is not the right answer here.
· May be dependent on uncertain timelines / success of IMS rollout
· Uncertain dependencies on in-home infrastructure (gateway, WLAN, PC etc)
· Hasn't yet got sufficient awareness to drive innovative 3rd-party developers etc. May suffer from UMA failure fallout


Non-IMS SIP-based dual-mode:
Positives:
· Less pre-occupation with "nice to have" seamless handover
· Puts the customer (or a "challenger" service provider) in control
· Takes advantage of the growing number of handsets with "naked SIP" functionality
· Can work in the enterprise with PBX-integrated mobility manager
· Should be suited for "least cost routing" applications
· Works OK in multi-access point environments Good solution for "challenger" operators like VoIP providers, ISPs, broadband firms, foreign mobile operators etc

Limitations:
· WiFi-enabled handsets still tend to be expensive, poor on battery life, limited in numbers & expensive
· Difficult to do low-latency handover
· Installation, configuration & support headaches for using 3rd-party software on phones
· Potential problems with user interface or application blocking on handsets which have been operator-customised or locked
· Requirement for solution provider to focus efforts on handset software development, integration, testing etc
· More difficult distribution / subsidy model for handsets Will work best in markets/segments with low operator involvement in handset supply

Cellular HomeZones (such as O2 Genion and Vodafone ZuHause):
Positives:
· Drives fixed-mobile substitution
· Possible to use dual numbers, fixed- and mobile
· Uses standard mobile numbers Homes still tend to want fixed connection for broadband, and maybe IPTV in future

Limitations:
· Works best in markets with low penetration of mobile outbound calls.
· Low cost" cell radius may be very wide, driving cannibalisation.
· Possible IPR issues
· May mean unacceptably high costs for inbound callers
· May need extra intelligence / infrastructure in the network Opportunity for bundling with "naked DSL" looks attractive if permitted

Cellular Picocells & Femtocells:
Positives:
· Picocells already proven to work in niche usage cases
· Need fewer picocells to cover an area than WLAN APs
· Adds network capacity in-building as well as just coverage
· Use normal cellphones rather than complex dual-mode ones
· Can be backhauled with a cheap IP/ADSL connections rather than a leased line
· Licensed spectrum so less risk of interference than using WiFi
· Proliferating number of picocell vendors, silicon suppliers, VARs / resellers and related switching / application providers
· Given a huge boost by recent Ofcom low-power spectrum auctions in the UK
· May well be driven by requirements for indoor use of HSDPA and UMTS Lots of interesting niche business cases

Limitations:

· Sub-$500 "Femtocells" for residential services still at prototype stage
· Possible complexities around spectrum management & RF planning if there are 1000's of picocells in a city
· Complexity dealing with IT / facilities management personnel on-site
· Security issues - is a picocell "genuine"?
· Enterprise PBX integration with cellular can be difficult at a practical level
· Some signs that operators will need to deploy overlay LANs
· May be problems with roaming agreements outside buildings
· May require end-user to manually re-select networks on handsets
· May be dependent on broadband provider
· Issues around gateway integration, support for residential customers on IT issues etc


Fixed + Mobile service bundling:
Positives:
· Much simpler than many FMC solutions
· Possible to gain good percentage of FMC financial benefits (customer lock-in, new services, family plans etc) with little technical investment
· Various enhancements like closed-user groups (call Family mobiles for free, etc) No need for expensive/complex dual-mode phones or on-handset custom software

Limitations:
· Only really suitable for hybrid fixed+mobile carriers, or MVNOs
· Doesn't improve indoor cellular coverage
· Limitations in future migration path (eg to IMS)
· May add complexity in sales / provisioning (eg transitioning multiple family members from existing services & numbers) Possibly difficult to tie-in prepay subscribers

VoIPo3G or VoIPoWiMAX:
Positives:
· Potential to replicate Skype or similar in the mobile domain
· Decouples access from service provider, improving competition & probably prices
· More spectrum becoming available
· Reduces need for WiFi in handsets
· Future coding schemes will improve radio resource efficiency above circuit-switched voice
· May be used initially as a "second line" eg VoIP for international calls
· Fits well with introduction of SIP-enabled handsets Likely to be embraced by operators in the long term (probably CDMA first with RevA/B)

Limitations:
· Data plans currently mitigate against use, especially when roaming
· Heavily dependent on cell capacity for guaranteed QoS
· Poor indoor coverage, esp for WiMAX >2.5GHz
· Few phone-type devices at present (only PDAs)
· At present, very inefficient way of using radio resource
· May be difficulties with handset integration (eg access to codecs, echo cancellation etc) Very early days in terms of devices, use experience, integration etc

W-CDMA - Terms

RB - Radio Bearer

The service provided by the Layer 2 for the transfer of user data between UE (User Equipment) and UTRAN (UMTS Terrestrial Radio Access Network). Also in page 28, 25.321: “Dynamic radio bearer control is performed by RRC, based on the traffic volume measurements reported by MAC.” Each User Entity may have several RBs. The maximum number of RBs for each User Entity supported at current release is:
1. Maximum=5: e.g. 1 signalling channel + 3 voice channels + 1 data channel;
2. Maximum=32: for all other configurations

RAB - Radio Access Bearer

Term used in UMTS to identify the service the AS (Access Stratum) provides to the NAS (Non Access Stratum) for transfer of user data between the UE (User Equipment) and the CN (Core Network).

CPCH - Common Packet Channel
This is a contention based UMTS channel used for transmission of bursty data traffic. This channel only exists in FDD (Frequency Division Duplex) mode and only in the uplink direction. The common packet channel is shared by the UE (User Equipment) in a cell and therefore, it is a common resource. The CPCH employs fast power control.

TFI - Transport Format Indicator
The Transport Format Indicator indicates the local UMTS air interface transport format to be used for the transmission time interval.

TFCI - Transport Format Combination Indicator
This is a representation of the current TFC (Transport Format Combination) being used. The TFCI is transferred across the air interface and allows the receiving layers to identify the current valid Transport Format Combination and hence, how to decode, de-multiplex and deliver the received data on the appropriate Transport Channels.

TCTF - Target Channel Type Field
The UMTS air interface uses the Target Channel Type Field to provide identification of the logical channel class on the FACH (Forward Access Channel) and RACH (Random Access Channel) transport channels. TCTF indicates if BCCH (Broadcast Control Channel), CCCH (Common Control Channel), CTCH (Common Traffic Channel), SHCCH (Shared Channel Control Channel) or dedicated logical channel information is being transported.

TB - Transport Block
In UMTS a TB (Transport Block) is defined as the data accepted by the physical layer to be jointly encoded. The transmission block timing is then tied exactly to this Layer 1 frame timing, e.g. every transmission block is generated precisely every 10ms, or a multiple of 10ms. Also in page 23, 25.321:”The Transport Blocks, shall be transmitted in the order as delivered from RLC. When multiplexing of RLC PDUs from different logical channels is performed on MAC, the order of all Transport Blocks originating from the same logical channel shall be the same as the order of the sequence delivered from RLC. The order of the different logical channels in a TBS is set by the MAC protocol.”

TBS - Transport Block Set
The Transport Block is defined as a set of Transport Blocks, which are exchanged between MAC and L1 at the same time instance using the same transport channel. A high rate transport channel carries more information and therefore potentially carries more transport blocks. Also in page 23, 25.321:”In the uplink, all MAC PDUs delivered to the physical layer within one TTI are defined as TBS. It consists of one or several TBs, each containing one MAC PDU.”

Transport Block Size

The Transport Block Size is the defined number of bits in a Transport Block. The Transport Block Size is always fixed within a given Transport Block Set. That is all Transport Blocks within a Transport Block Set are equally sized.

Transport Block Set Size
The Transport Block Set Size is defined as the number of bits in a Transport Block Set.

TTI - Transmission Time Interval
This is defined as the inter-arrival time of TBS (Transport Block Set), and is equal to the periodicity at which a Transport Block Set is transferred by the physical layer on the radio interface. It is always a multiple of the minimum interleaving period (e.g. 10ms, the length of one RF (Radio Frame)). The MAC (Medium Access Control) delivers one Transport Block Set to the physical layer every TTI.

Transport Bearer:
Service provided by the transport layer and used by frame protocol for the delivery of FP PDU

Transport Format
Transport Format is defined as a combination of attributes which include: error protection, timing, interleaving, bit rate and mapping onto physical channels.

TFS - Transport Format Set
The Transport Format Set is the set of different Transport Formats associated to a Transport Channel.

TFCS - Transport Format Combination Set
The Transport Format Combination Set is defined as a set of Transport Format Combinations on a Coded Composite Transport Channel.

CCTrCH (Coded Composite Transport Channel)
A data stream resulting from encoding and multiplexing of one or several transport channels.

TFC - Transport Format Combination
The physical layer multiplexes one or several Transport Channels onto a Coded Composite Transport Channel (CCTrCH). These Transport Channels each have defined transport formats (maybe from a Transport Format Set) which are applicable. However, at a given point of time, not all combinations of transport channels and their associated formats are permitted, hence a subset is defined. The Transport Format Combination is one of the subset, which identifies the transport channels with their chosen format that will make up the Coded Composite Transport Channel.

CFN (Connection Frame Number)
CFN counter. CFN is the frame counter used for the L2/transport channel synchronisation between UE and UTRAN. A CFN value is associated to each TBS and it is passed together the MAC-L1 SAP. CFN provides a common frame reference (at L2) to be used e.g. for synchronised transport channel reconfiguration.
The duration of the CFN cycle is longer than the maximum allowed transport delay between MAC and L1 (in UTRAN side, between SRNC and Node B, because the L1 functions that handle the transport channel synchronisation are in the Node B). Range: from 1 to 255 frames. When used for PCH the range is 0 to 4095 frames.

3GPP UMTS Draft Specifications

21 series Requirements Specifications
22 series Service aspects
23 series Technical Realization
24 series Signaling Protocols (MS - Core Network)
25 series Radio Aspects
26 series Codec (speech, video etc)
27 series Data
28 series Signaling Protocols (RSS - Network Part)
29 series Signaling Protocols (NSS)
30 series Program Management
31 series UIM
32 series Operation and Management
33 series Security Aspects
34 series Test Specifications

W-CDMA - Radio Bear Realization

The UTRAN standard does not mandate how to realize radio bearers, i.e. what user plane protocol modes should be selected by RRC for a specific bearer service request. Below some typical realizations are outlined.

Conversational bearers may use PDCP if they originate from the Internet and have headers that should be compressed. For voice services originating from PSTN, PDCP is typically not used. The delay requirements are typically too stringent to allow for retransmission of erroneous data. Therefore unacknowledged RLC is used if segmentation of higher layer data units is required, and otherwise transparent RLC is used, which is the typical case for voice bearer services. The delay requirements typically require that the dedicated MAC mode is used. Streaming bearers with very stringent delay requirements may be realized in the same way as conversational bearers. However, for bearers with looser delay requirements, it is possible to use acknowledged RLC and common/shared MAC, which may yield higher capacity. PDCP usage is not affected by this.

Interactive and Background bearers typically originate from the Internet and hence PDCP is used. The delay requirements allow for acknowledged RLC and common/shared MAC. High priority Interactive bearers could use the dedicated MAC mode.

• One Physical Control Channel and one or more physical data channels form a single Code Composite Transport Channel (CCTrCh). There can be more than one CCTrCh on a given connection but only one physical layer control channel is transmitted in such a case.
• Frame Structure of Transport Channels: The UTRA channels use the 10ms radio frame structure. The longer period used in the system frame period. The System Frame Number (SFN) is a 12 –bit number used by several procedures that span more than a single frame. Physical layer procedures, such as the paging procedure or random access procedure, are examples of procedures that need a longer period than 10ms for correct definition.
• Scrambling code: It is needed to separate terminals or base stations from each other. It would not matter if the actual spreading were done with identical code for several transmitters. The chip rate As the chip rate is already achieved in the spreading by the channelisation codes, the symbol rate is not affected by the scrambling.

SUPL (Secure user plane location)

A standards-based protocol that allows a mobile handset client to communicate with a location server over an IP connection, is a standard promoted by the OMA standards body and supported by location industry leaders. Openwave's SUPL support extends Openwave's established user plane expertise from CDMA and iDen into the GSM and WCDMA network areas.

SUPL is not another positioning procedure, but rather an alternative or complementary positioning architecture based on IP instead of SS7 signalling.

A positioning solution based on the user plane is less dependent on the core network and also reduces the load on the control plane.

In addition to much higher accuracy (positioning of within 5-10 meters), SUPL A-GPS offers the following benefits compared to stand alone GPS:

• Faster time to first fix of GPS satellite
• Better coverage
• Longer battery life
• Built into the device

Openwave Location Manager gathers a subscriber's location from available sources including cell-ID and Assisted-GPS (A-GPS) to securely deliver information to the requesting application. Providing accurate location information is key to the success and usability of location-intelligent services. A pioneer in SUPL solutions, Openwave deployed the first successful commercial user plane solutions at major wireless operators in several countries.

Openwave Location Manager provides several feature modules, including:

• Content & Applications to enable its customers to offer state-of-the-art location services from a selection of applications
• Access Management for application requests, subscriber privacy, and billing and operation systems integration
• Positioning Management to obtain and/or calculate a subscriber's position using SS7 protocols, IP based technologies and/or handset location solutions
• User Plane Management to support handset location technologies, including OMA SUPL specifications for A-GPS

Openwave's messaging, location, browsing and content services span all networks and devices. Today, Openwave software is used by more than 100 mobile operators, broadband providers and Mobile Virtual Network Operators (MVNOs) to enable access to data services for more than 500 million consumers around the world.

New Congestion Control System for 3G FOMA Network

From NTT DoCoMo's PR DoCoMo to Unveil New Eight FOMA "9 Series" Phones.


ASIA Japan : NTT DoCoMo said they would separately manage call and data packet transmission congestion over the 3G FOMA™ network to prevent voice traffic congestion control from affecting packet communication traffic and vice versa.

Currently, excessive congestion in either voice or data transmissions can force DoCoMo to limit network usage for both voice and data in order to prevent network breakdown.

One result of the move is the increased ability to successfully transmit text messages via i-mode mail, or to DoCoMo's i-mode™ Disaster Message Board service, even if voice traffic should rise sharply during a major disaster. The i-mode Disaster Message Board service, launched on January 17, 2004, enables i-mode subscribers to post text messages on a special i-mode site.
The new system will initially apply only to selected handsets — D902iS, F902iS, N902iS, P902iS, SH902iS, DOLCE SL, SH702iS, D702iF, N702iS, P702iD, and N902iX HIGH-SPEED.

A similar control system for the 2G mova™ network was implemented in April 2004.