1. This document is offered compliments of
BSP Media Group. www.bspmediagroup.com
All rights reserved.

2. Mobile
Number
Portability
Implementa<on
and
Management
-­‐
Dar
es
Salaam,
Tanzania,
15-­‐16
nov
2012
Efficient
and
simple
por1ng
processes
make
one
day
por1ng
a
reality
Raymond
Bouwman,
Rabión
Consultancy

3. About
Rabion
Consultancy…
NP
and
Numbering
Management
and
Domain
Naming
projects:
TRA
Bahrain,
OUR,
Jamaica,
TRC
Jordan,
TAS
Suriname,
European
Commission
DG
CNECT,
DTZ
Aruba,
BTP
St.
Maarten,
BTP
Curacao
etc.)
Operators
(KPN,
T-­‐Mobile,
Orange,
UTS)
Service
Providers
Enablers
(
Vodafone
Roaming
Service)
Suppliers

5. AGENDA
1) The
reality
of
shortening
por<ng
<mes
2) Stats
3) What
is
causing
the
customer
experience?
4) Drivers
behind
5) Who
need
fast
por<ng
<mes?
6) Drawbacks
of
fast
por<ng
<mes
7) Conclusions
8) Recommenda<ons

7. Why
‘one
day
por<ng’
has
become
the
standard/benchmark?
Brussels,
23
March
2009
EU
Telecoms
Commissioner
calls
for
consumer
right
to
change
phone
operator
in
1
day
"Europe
should
be
ambi1ous
when
it
comes
to
empowering
our
consumers,"
says
Commissioner
Reding
in
her
video
message.
"Because
empowered
consumers
are
the
best
recipe
for
strong
compe11on
on
the
market,
investment
into
a=rac1ve
services
and,
at
the
end,
lower
prices
for
all.“
"I
want
all
Europeans
to
be
able
to
switch
their
phone
operator
–
whether
mobile
or
fixed
–
within
one
single
day,
as
it
is
already
the
case
in
Ireland
and
in
Malta.“
• 6

8. Examining
the
por<ng
<mes:
Average
number
of
days
to
port
a
number
(EU)
MNP
FNP
2011
2,5
3,8
2010
?
?
2009
4,1
5,9
2008
8,5
7,5
Not
en<rely
clear
what
‘average’
means
(average
over
countries,
average
over
ported
customer,
or
weighted
average
over
the
total
subscribers
etc.

9. Number of days needed to port a fixed number, October 2010 - October 2011
12
2010 2011
10
8
6
4
2
na
na
na
na
na
0
BE BG CZ DK DE EE EL ES FR IE IT CY LV LT LU HU MT NL AT PL PT RO SI SK FI SE UK EU
EU,
DG
Connect,
Digital
Agenda
Scoreboard
2010-­‐2011

10. Number of days needed to port a mobile number, October 2010 - October 2011
12
2010 2011
10
8
6
4
2
na
na
0
BE BG CZ DK DE EE EL ES FR IE IT CY LV LT LU HU MT NL AT PL PT RO SI SK FI SE UK EU
EU,
DG
Connect,
Digital
Agenda
Scoreboard
2010-­‐2011

11. Fixed number portability transactions, 2010 (Jan-Sept) - 2011 (Jan-Sept)
18%
2010 2011
16%
14%
12%
10%
8%
6%
4%
2%
na
na
na
na
na
na
0%
BE BG CZ DK DE EE EL ES FR IE IT CY LV LT LU HU MT NL AT PL PT RO SI SK FI SE UK EU
EU,
DG
Connect,
Digital
Agenda
Scoreboard
2010-­‐2011

12. Mobile number portability transactions, 2010 (Jan-Sept) - 2011 (Jan-Sept)
10%
2010 2011
9%
8%
7%
6%
5%
4%
3%
2%
1%
na
0%
BE BG CZ DK DE EE EL ES FR IE IT CY LV LT LU HU MT NL AT PL PT RO SI SK FI SE UK EU
EU,
DG
Connect,
Digital
Agenda
Scoreboard
2010-­‐2011

13. Learning
from
case
studies
and
best
prac1ce
examples
of
effec1ve
por1ng
procedures
and
quick
por1ng
1mes..
Less
that
24
hours
:
USA
(2,5h),
Canada
(<3h),
Australia
(3h),
New
Zealand,
Ghana,
Chile
(2h),
Ireland,
Malta
(4h)
…
1
day
:
UK,
Singapore,
Lithuania,
Luxemburg,
Spain,
Denmark,
Poland.
More
than
1
day:
all
the
rest….
In
Ghana
‘17
minutes
and
19
seconds’,
but
45%
within
5
minutes
(while
wai<ng
in
a
shop)

14. Por<ng
process
-­‐
<me
components
Wai<ng
<me
before
PR
submission
to
donor
Wai<ng
Time
before
execu<on
Processing
<me
at
donor
Execu<on
Time
Picture
edited
from
European
Commission
Commijee,
report
2010

15. EU
Universal
Service
Direc<ve
Por<ng
of
numbers
and
their
subsequent
ac<va<on
shall
be
carried
out
within
the
shortest
possible
<me.
In
any
case,
customers
who
have
concluded
an
agreement
to
port
a
number
to
a
new
undertaking
shall
have
that
number
ac<vated
within
one
working
day.

16. Defini<ons
Examples
’
Por<ng
Time’
1) Time
between
submission
of
the
Por<ng
Request
by
recipient
and
the
comple<on
of
the
number
por<ng
execu<on
(including
the
ac<va<on
at
the
new
network)
2) Time
between
approval
of
the
Por<ng
Request
by
Donor
and
the
comple<on
of
the
number
por<ng
execu<on
(including
the
ac<va<on
at
the
new
network)
3) The
actual
Por<ng
Execu<on

17. Defini<ons
Examples
’
Por<ng
Time’
1) Time
between
submission
of
the
Por<ng
Request
and
the
comple<on
of
the
number
por<ng
execu<on
(including
the
ac<va<on
at
the
new
network)
2) Time
between
approval
of
the
Por<ng
Request
and
the
comple<on
of
the
number
por<ng
execu<on
(including
the
ac<va<on
at
the
new
network)
3) The
actual
Por<ng
Execu<on

18. Other
points
of
ajen<on
on
Por<ng
Time
• Difference
between
Recipient-­‐led
process
and
a
Donor-­‐led
process
(end-­‐to-­‐end
cycle
is
different)
•
Service
Providers
or
resellers
in
the
chain:
they
may
need
processing
<me
• What
if
Por<ng
Request
is
rejected,
is
this
part
(Time!)
of
the
process?
• What
is
a
working
day?
Por<ng
Only
during
Working
Hours/Working
Days,
or
24/7
por<ng?
What
if
requests
arrive
on
Friday
at
16.55
just
before
closing?
• Condi<ons
not
allowing
NP
in
due
<me
(within
the
requested
por<ng
<me
frame)?
Postpaid
in
par<cular
(Contract
binding
period,
terms
of
no<ce,
bad
debt,
suspension)
• Groups
of
numbers
• Physical
Limita<ons
that
need
<me
(PSTN
fixed,
SIM
distribu<on!),
• Central
Systems
Quota
management

19. What
is
causing
the
customer
experience?
1)
The
por<ng
method
procedure
2)
The
technical
system
implementa<on
4)
Terms
and
Condi<on
for
rejec<ng
the
Por<ng
Request

20. 1)
Por<ng
Method
• Simple
Interoperator
Messaging
Processes
• Effec<ve
valida<on
rules
(but
s<ll
fulfill
security
requirements
and
prevent
fraud)
• Only
require
customer/subscrip<on
data
relevant
to
the
process
• Electronic
authorisa<on
instead
of
handwrijen
signatures,
no
exhange
of
paper
forms

21. ‘Go
with
flow’
por<ng
RECIPIENT
CENTRAL
SYSTEM
DONOR
Tcs
Por<ng
request
T1
Donor handling time
Por<ng
request
ACCEPT
T2
Por<ng
execu<on
Execution
at
Recipient
T3
Execution at Donor
Por<ng
executed
1) No
specific
por<ng
Date
and
at
Time
agreed.
Por<ng
happens
whenever
it
happens!
2) Receiving
a
message
just
triggers
the
next
step
message
3) Por<ng
<me
is
T1
+
T2
+T3
+
Tcs’
+
Tcs’’
+
Tcs’’’
+
Tcs’’’’

22. ‘
Planned
Time’
Por<ng
RECIPIENT
CENTRAL
SYSTEM
DONOR
Por<ng
request(por1ng
date/1me)
T1
Donor handling time
Por<ng
request
ACCEPT
Wai<ng
<me
T2
Por<ng
execu<on
Por<ng
T3
Execution at Donor
Date
&
Time
Por<ng
executed
1) Request
for
specific
por<ng
Date/Time.
Por<ng
Execu<on
waits
un<l
por<ng
Date/Time
has
arrived.
2) Capability
to
schedule
Number
Por<ng
to
take
place
in
the
future
Por<ng
<me
is
T1
+
T2
+T3
+
Tcs’
+
Tcs’’
+
Tcs’’’
+
Tcs’’’’
+
Wai<ng
Time

23. 2)
Technical
system
implementa<on
• Automated
procedures,
no
(or
minimal)
manual
interven<ons
• No
Batch
Processes
(<me
consuming,
non-­‐real
<me),
but
event-­‐
driven
• Overall
Data
Consistency
and
low
fault
rates
(Central
Database
solu<on,
and
Central
Agent/Clearing
system)
• Provisioning
Process
(Number
Ac<va<on)
must
be
efficient
and
reliable,
and
well
integrated
with
Por<ng
Execu<on

24. 3)
Terms
and
condi<on
Reasons
not
to
accept
a
Por<ng
request
(non-­‐prepaid)
e.g.
:
• Contract
End
date
not
reached
• Terms
of
No<ce
period
before
a
subscrip<on
has
to
be
legally
terminated
• Outstanding
Payments
• Bad
Debt
or
other
liabili<es
unresolved
Allowing
any
of
these
circumstances
to
reject
a
por<ng
request
will
not
lead
to
the
best
possible
por<ng
<mes
NP
should
be
free
of
barriers
if
fast
por<ng
<mes
are
desired.
For
always
fast
por<ng
<mes,
keep
Contractual
T&C
and
Por<ng
Rules
separately

25. Understanding
the
drivers
behind
reducing
por1ng
1mes
• In
general,
Regulators
are
the
drivers
to
short
and
efficient
por<ng
• (Many)
Operators
may
have
objec<ons
and
see
complica<ons
(primarily
commercial
reasons)
• More
important
is
to
look
at
the
customer:
Q:
Does
‘one
por<ng
<me
fits
all’?
A:
In
general
shortening
Por<ng
Times
is
a
good
thing,
but
the
Por<ng
Time
should
be
just
what
the
customer
needs,
and
not
necessarily
the
shortest
possible
<me

26. Why
improve/shorten
the
por<ng
<me?
Because
Telecom
Regulators
want
it
•
• Maturity
of
NP
solu<ons.
Because
it
is
technically
possible
• Because
Customers
do
not
want
to
wait,
if
no
reason
• Improvement
of
the
Customer
Experience,
process
that
is
easier
to
understand
• Contribu<on
to
more
level
of
compe<<on
in
the
Market
• Benchmark
between
countries:
faster
is
bejer!

27. Is
a
minimum
por<ng
<me
required
for
all
types
of
customers?
CONSUMER
PREPAID
(shop
order)
:
YES,
Less
than
10
minutes
(while
wai<ng
at
the
point
of
sales)
PREPAID
ON
LINE
SALES:
NO,
several
days
available,
but
quick
execu<on
may
be
triggered
by
customer
once
SIM
card
received
LARGE
BUSINESS:
NO,
customer
needs
prepara<on
and
<me
for
migra<on,
Typically
4-­‐6
weeks
FIXED
PSTN:
NO,
physical
connec<on
or
LLU
needs
<me,
Typically
2
weeks
VOIP:
YES
even
for
online
sales
CONCLUSION:
Do
not
get
hung
up
on
ultrashort
por<ng
<mes
as
a
rule,
but
make
the
Por<ng
Process
and
the
<ming
fit
to
the
customers’needs

28. DRAWBACKS
on
FAST
PORTING
TIMES?
1) ‘impulsive
buying’,
no
<me
to
think
it
over
twice.
2) No
<me
to
ask
the
Donor
for
a
bejer
deal!
(Remember
that
MNP
is
a
tool
for
more
compe<<on
and
bejer
pricing)
3) Non-­‐paid
customers
may
be
surprised
by
unexpected/
unknown
pay-­‐off
costs?
4) Higher
risk
to
‘Slamming’?
5) Prepaid
Credit
at
the
old
network
lost?
6) No
<me
to
ask
the
Donor
for
a
bejer
deal!
Remember
that
MNP
is
a
tool
for
more
compe<<on
and
bejer
rates.
The
number
of
ports
nor
the
por<ng
<me
dura<on
are
goals
in
itself

29. Discussion
Tanzania
Por<ng
Time
defini<on?

30. Conclusions
1) Trend
that
average
por<ng
<mes
are
decreasing.
Por<ng
<mes
of
1
day
or
less
have
become
common
.
Near
real-­‐<me
por<ng
bas
become
the
reality.
2) The
defini<on
of
‘Por<ng
Time’,
and
monitoring
has
to
be
carefully
considered.
3) The
barriers
to
reach
fast
por<ng
<mes
(1
day
or
less)
are
primarily
of
a
legal
nature.
Technical
barriers
can
be
resolved.
4) Trade-­‐of
between
‘Fast
Por<ng
Times’
and
‘Por<ng
Reject
Reasons’
5) The
Por<ng
Time
is
not
a
‘fit
for
all’.
Various
type
of
users
and
situa<ons
need
differen<a<on
depending
on
customer
requirements.

31. Recommenda<ons
Regulatory
authori<es
have
to
:
• Look
into
‘Por<ng
Time’
in
a
detailed
and
way
• Provide
clear
and
understandable
defini<ons
• Set
realis<c
and
representa<ve
targets,
not
only
for
por<ng
<me
but
also
for
valida<on
<me,
down
<me
etc.
• Avoid
‘one-­‐fits-­‐all’
objec<ves
• Take
into
account
difference
between
customers,
proposi<ons,
fixed
vs.
Mobile
• Provide
clear
instuc<ons
for
monitoring
and
repor<ng
por<ng
<me
performance