Portability Specification
Statement of Reasons
1. Frameworkhttps://www.anacom.pt/render.jsp?contentId=55129
2. Analysis of the modifications introduced to the Specificationhttps://www.anacom.pt/render.jsp?contentId=55130
3. Other issueshttps://www.anacom.pt/render.jsp?contentId=55131
4. Determinationhttps://www.anacom.pt/render.jsp?contentId=55132
Portability Regulation no. 87/2009 of 18 February (Regulation), approved on 4 February 2009 by the Board of Directors of ICP-ANACOM, amends Regulation no. 58/2005 of 18 August and simultaneously introduces, namely, Article 4, which defines how the Regulation will enter into force. Thus, item 2 of this Article determines that ''Annexes I and II of the Portability Specification shall be reviewed and updated by the companies with portability obligation and by the Reference Entity under ICP-ANACOM coordination, and released at this Authority’s website within two months after the publication of the Regulation''.
In order to fulfil these provisions, ICP-ANACOM sent a letter to all providers with portability obligations and to the Reference Entity (RE), summoning them for meetings in order to start the works for updating the mentioned annexes I and II, as provided for in the Portability Regulation.
Six work meetings were held in this context, on 10 March, 23 and 24 March and on 6 and 7 April, with the companies who decided to participate. Three meetings of the Working Group for the Technical Interface between Networks (WG-NT) analyzed and specified the modifications regarding annex I, and three meetings of the Working Group for Administrative Processes (WG-AP) did the same for annex II.
Several different ways to implement the amendments made to Regulation no. 58/2005 - Portability Regulation – were discussed during the meetings, with the companies presenting several contributions, as well as their opinions, interests and constraints when facing the choice among several options.
Therefore, when the regulation’s provisions enabled several technical standardization solutions for the specification, and no agreement was reached on the solution to be adopted among the companies, ICP-ANACOM would weight the several arguments and interests, and would usually make its option considering the position of the majority of the companies present. This procedure is recorded in the minutes of the proceedings, which were approved by the companies that participated in those meetings.
The following analysis briefly describes the most relevant modifications made to the Specification - Annex I and Annex II - and also contains the grounds for the selected option for the cases where no agreement was reached among the companies.
2. Analysis of the modifications introduced to the Specification
Firstly, the Specification approved and published by ICP-ANACOM dates from 2001. However, given that the specification is made up of two fundamentally technical and operational documents, they actually assumed their own autonomy and were subject to updates resulting from improvements or simple adjustments that were proposed, shared and publicized among the interested parties - providers with portability obligations and the Reference Entity (RE) - but which were not published on ICP-ANACOM's website.
In fact, by defining the Portability Regulation within the corresponding Regulation, approved and published in 2005, as a set of technical and procedural rules approved by a determination of the Board of Directors of ICP-ANACOM of 28 July 2001, at the same time, that set of rules were made autonomous, as its definition states ''without prejudice to amendments that may be introduced whenever appropriate''. Since the specification was an operational and ''live'' document, it was considered it would require greater dynamics concerning the approval/conciliation procedure, which would hardly be compatible with the greater stability intended for a regulatory provision - in this case, a Regulation.
As reality showed, these technical documents were subject to modifications and supplements which, in spite of their latest version not being published at ICP-ANACOM’s website, do not hinder companies’ general good performance in the implementation of portability.
Thus, the documents that make up the Portability Specification not only contain the modifications following the Regulation’s amendments, but also the updates that were implemented by providers and the RE since 2001.
Each document of the Specification - Annex I and Annex II - was analyzed within its own working group – WG-NT and WG-AP – while the analysis of the modifications that were made is carried out separately.
2.1 Analysis of Annex I - Technical Interface between Networks
The modification with greatest impact on this specification derives from the requirement to contemplate the situation of service extinction by a given company.
Although the regulation has defined a set of principles, rules and conditions associated to service extinction, it did not define the way to implement those rules. 4 scenarios were identified in order to implement service extinction.
2.1.1 Analysis of scenarios
Four possible scenarios were identified, with scenarios 3 and 4 receiving the greatest attention. Scenario 3, directly resulting from the Regulation, provided that:
- Calls directed to numbers from numbering blocs granted to the company that extinguished the service, use the previous search methodology for routing All Call Query (ACQ), thus eliminating the need to release the call with cause no. 14 (REL#14);
- Active numbers of the numbering blocs are always considered ported numbers;
- Non-active numbers, as well as the numbers that may be deactivated due to service deactivation by the customer, and after a quarantine period 1, are returned to ICP-ANACOM, and become unavailable 2 on the NNP, for allocation.
Scenario 4 assumed that:
- The numbering blocs allocated to the company that extinguishes the service are allocated to another company by means of a selection procedure, based on the largest volume of ported numbers from that company's numbering blocs (ported-out numbers). This scenario presented two variants; one, where the reckoning of the ported numbers is based on the total volume, and the other, where each bloc from the company with the extinct service is handled separately, being re-allocated to the company with eligible conditions (largest amount of ported-out numbers) for that bloc.
Since this scenario did not satisfy the requirement of rapidly responding to an extinction situation, particularly since it caused the interruption of the service to the customers with numbers from the extinct company, ICP-ANACOM considered that, should scenario 4 be adopted, it would also be necessary, during the extinction, to have a scenario of type 3. Thus, the existence of a transition period coinciding with the quarantine period should be foreseen, where calls would be routed not using the reception of REL#14.
After the quarantine period and with the choice of the operator(s) to which the numbering blocs would be allocated, the initial methodology would be restored, i.e., the Query on Release (QoR) method.
After solving the technical constraints initially pointed out by some operators in the implementation of scenario 3, both scenarios' advantages and inconveniences were analyzed. Following is a summary of the most frequent arguments presented by providers:
- In favour of scenario 3 - it is a solution where each provider is autonomous, with no costs associated to the work and processing in sending signalling to another operators' network;
- Against scenario 3 - does not provide any solution for messaging (non-call related 3) services originated abroad;
- In favour of scenario 4 - also has a response in the case of message communications originated abroad;
- Against scenario 4 - it is a solution requiring a procedure for reallocating numbering blocs and a transition solution in which messaging (non-call related) services would not operate and would impose different types of costs for providers, including the payment of fees for the use of numbers.
All providers were in favour of scenario 3, except PT Group and Radiomóvel (although in a scenario of exemption of the fees for the use of numbers). Colt stated having no preferences, mentioning that it had the conditions to prepare for both scenarios.
Therefore, scenario 3 was chosen.
Regarding scenario 3's deficit concerning non-call related services, it was considered premature to adopt a technical solution at this stage, since it is still not standardized for calls with international origin.
In this context, mobile telephone service operators (including a MVNO provider - ZON) presented a document with proposed actions to be developed in order to find a solution for these services, basically concluding that:
- It is not possible to establish a Technical Interface Specification that completely solves all extinction situations;
- In case of the extinction of one of the current MNO, no reasonable or feasible solution was found, and therefore it should require an evaluation of the procedure to be adopted in order to minimize the impact for consumers and the remaining operators;
- This situation can also occur in case a future small size MNO or a Full MVNO exists;
- In the case with light MVNO, operators supporting these providers will temporarily assume (for no more than 6 months) the responsibility to route this type of communications.
Furthermore, this document proposes that this matter be developed within the scope of a Working Group to start operating in September.
2.1.2 Annex I
In light of the above, the Specification of the technical Interface between networks - Annex I - had the following major modifications:
- Integration of a document published at ICP-ANACOM’s website with the solution now being used for non-call related services;
- Introduction of the scenario foreseeing the implementation, for specific numbering blocs (of extinct services), of the routing methodology based on the ACQ solution or a similar routing technique, therefore suppressing the release message back with cause no. 14 (REL#14);
- Inclusion of the mobile operators’ document as Specification's Appendix B.
2.2 Analysis of Annex II - Administrative Processes
The modifications with greatest impact on this specification derive not only from the demand to contemplate the expected extinction of a service by a given company, but also to adjust the timers to the new time limits, and the message and denial causes to the new conditions in force for the portability requests.
Each aspect is analyzed separately.
2.2.1 Service extinction
Article 12 of the amended Regulation already foresaw a role for the RE within the scope of service extinction. Thus, it foresees that, in the absence of the provider that extinguishes the service, the RE, on behalf of that provider, will operate as the holder/donor provider (DP), in the case of the first portability request since the extinction of the service until 3 months after that date (quarantine period), for the numbers of customers of the extinct service.
In this sense, a section was introduced describing the operations emulated by the RE.
Furthermore, the number return procedure requires contemplating additional actions to be developed by the RE. The option for scenario 3 on the technical Interface between networks also foresaw a warning function by the RE at the end of the return procedure started by the first provider holding a number of blocs allocated to the company with the extinct service, in order to warn about its return to ICP-ANACOM. On the other hand, if scenario 4 had been chosen, it should operate a massive alteration of NRN 4, in this case with a direct impact on providers.
2.2.2 Timers
One of the major changes to the Regulation was the reduction of the minimum time limit for the porting request prior to the date scheduled for the portability, thus granting the final user a much smaller time than currently for the provision of this functionality. This reduction, from 5 to 2 working days in mobile numbers, and from 8 to 2 working days in the case of other numbers, did not alter the way to count the times.
However, PT Group invoked that the way to count the times foreseen in the Portability Specification in force since 2001 and later transposed to Regulation no. 58/2005, did not comply with the legal time counting regime, established in the Civil Code, since these times were counted in working hours while being expressed in working days.
ICP-ANACOM sustained that the time limits foreseen in the Amended Regulation were defined according to assumptions that were always taken into account by the RE when validating the electronic portability requests, and therefore that should be the Regulation's reading.
It was also clarified that the reference hour currently considered in the validation of the electronic portability request by the RE, for the range of the first time option, is the middle point of that window (11:30 hours, 16:30 hours or 19:30 hours).
This being a major issue that goes beyond the scope of the specification, requiring another level of approach and of procedure, the counting of ''working day'' maintained the assumption of ''24 consecutive hours counted on working days''.
Another timer that caused some debate was the timer that establishes the minimum time limit for cancelling a portability request. In this case the Regulation does not determine a particular value, defining only the terms under which the cancellation may be or may not be made. Some providers stated their concern for not being able to respond to a change of the subscriber's intentions, ICP-ANACOM having mentioned that it is hard to conciliate short deadlines for portability with the ''right to repent''.
On this matter, ICP-ANACOM simply underlined the need for all operators to feel ''comfortable'' with the value that would be defined, which, it understood, should be the highest of the proposed values, in order to prevent false number portability by providers who had not complied with the cancelation request in due time. The value agreed among operators for this timer was 12 hours.
Lastly, and on the side of the modifications established by the Regulation, the value of the timer that enables the sending of the several electronic requests that make up a coherent request 5 was doubled. It was a proposal of the Working Group as an alternative to PT Group's more complex initial proposal, to accept coherent requests with messages not ordered sequentially, and was also well accepted by that business group.
2.2.3 Conditions for Portability Requests
Another major modification to the Regulation concerns the elements to be stated on the portability request and, consequently, the reasons for rejection, should those elements be missing or incorrect. Furthermore, suppressing the mandatory sending of some elements from the Regulation led to the extinction of rejection causes.
On the other hand, if reducing the time limit to obtain portability mainly favours consumers, in order to achieve that reduction without security losses for the consumer it is essential to set conditions associated to the request facilitating its automation, in terms of computer processing.
Under this understanding and with the agreement of most providers, the provisions of the Regulation were fulfilled regarding the elimination of the obligation to send the address on the electronic requests for the portability of geographic numbers, and the establishment of the obligation to send an identification number of the subscriber.
Following a proposal presented by ZON to extend the field for the name of the subscriber, given its past experience, where 25% of the customers’ names were truncated, the advantages and costs were weighted and it was considered by the majority that it would be advantageous to increase the length of the name field, albeit this being a supplementary element under the new regulation.
Providers had a favourable reaction towards the proposal recovered by ICP-ANACOM, presented during the Portability Regulation Public Consultation, which suggested sending the SIM number in the portability request, in order to implement the telephone service at a fixed location over GSM/UMTS and to facilitate subscriber identification.
During the consultation procedure it was also identified the need to standardize SIM's precise format, a number that must be sent in the mobile number requests. This modification received consensus and it was decided that this field should be filled with a complete identifier, based on Recommendation E.118 6 from ITU-T (without check sum), and that the request would be rejected should it not be completely filled out.
Regarding the motives for rejecting electronic portability requests, they should be based on the principle of having a rejection cause code for each motive. However, on one hand, the portability specification was created before Portability Regulation no. 58/2005 and therefore some rejection causes are outdated, and on the other hand the Amended Regulation eliminates and creates other rejection causes. In spite of the existence, as a precautionary measure, of a generic rejection code which requires filling an observation field to state the problem of the request, minimizing the use of that generic code will contribute to procedure agility and transparency.
Under this understanding and with the agreement of most providers, several rejection causes were eliminated and created. Following a proposal by Vodafone and with the agreement of all operators except PT Group, the cause related to rejection due to Ownership/Identification was further divided. This division was grounded on the fact that it allowed for the clarification of the rejection cause – error in the name or error in the identification document number - thus facilitating the correction of the wrongly sated element in the electronic request for the same number.
Lastly, a PT Group proposal was accepted regarding using the fields available on the portability request's confirmation message and on the return message, in the case of simultaneous requests for portability with loop return, in order to facilitate synchronization between both procedures.
2.2.4 Others
PT Group stated its concern regarding the interface supporting communications between the operators and the RE, considering that its current capacity is not sufficient. In this sense, PT Group supported that procedural specifications should be review in this point.
The understanding expressed by most of those present (providers and RE) was that that capacity depends form the traffic generated by each provider, and therefore each provider should be responsible for sizing its connection. Since this was already stated on the specification’s corresponding point, it was not considered necessary to make any modifications.
Lastly, it was considered essential to create the conditions to test the modifications to the procedural specification during the implementing stage. The RE already informed that it intends to release the solution according to this modified specification, in the Development environment and for testing, one month before its entry into force.
Although on the side of the modifications to the Regulation, but since it was considered important for this group, ICP-ANACOM presented a software application supported on its own systems that is a considerable improvement from the current portability Extranet, in terms of features.
2.2.5 Annex II
In light of the above, the Specification of administrative Processes for operator portability - Annex II - had the following major modifications:
- Adoption and translation (from English) of the basic document, in its version 2.04, of the Specification of Administrative Processes for Portability kept by the RE and available on the portability Extranet.
- Introduction of a section with the specification of the functions to be carried out by the RE when it emulates a provider that has extinguished the service (section 3.10).
- Definition of new values for the timers:
- T3 (Maximum response time for a porting request): 24 consecutive hours counted on working days – according to item 7 of Article 12 of the Regulation;
- T4/T4M (Minimum time until porting (fixed) / Minimum time until portability (mobile)): 48 consecutive hours counted on working days according to item 5 of Article 12 of the Regulation;
- T16 (Time limit for sending NP Return): 2 days – according to item 1 of Article 16 of the Regulation;
- T2 (Maximum time to send all messages in a coherent request): 60 minutes – to improve the procedure for sending coherent requests;
- T9 (Point of no return of a porting request) and
- T13 (Point of no return of a NRN alteration): 12 hours.
- Modifications and additions concerning the format of messages or parameters:
- On message NP Request, the codification of parameters CustomerStreet, CustomerLocation and CustomerCodeAndLocation, changes from mandatory to optional;
- On message NP Request, the state of parameters CustomerDocumentIDType and CustomerDocumentID, is changed from to optional mandatory;
- On message NP Request, the state of parameter CustomerSIM is changed from ''not applicable to the fixed network'', to ''optional'';
- On messages NP Return and NP Request Confirmation, parameters Auxiliary1, Auxiliary2 and Auxiliary3 are introduced and designated for functions LocalLoopNumber, LocalLoopCoordinates and LoopHDFTermination in order to identify the loop to be returned, being optional. The information on those parameters is as follows:
- Auxiliary1 - Local Loop Number, with a 10-character length;
- Auxiliary2 - Loop HDF Block (HDF Bloc), with a 2 character length;
- Auxiliary3 - Loop HDF Termination (HDF Termination), with a 3 character length;
- Increase of the length of parameter CustomerName from 50 characters to 80 characters;
- Reduction of the length of parameter CustomerSIM from 20 characters to 19 characters;
- Introduction of code ''3=Nomadic'' in parameter TypeOfNumber;
- Addition of the following codes in parameter CustomerIDType:
- 3=Residence Title;
- 4=Citizen Card.
- Modifications to rejection causes:
- The following causes for rejection were eliminated, having been marked by marked as ''Reserved for future use'':
- Cause 301 (Lack of contract termination/alteration);
- Cause 303 (Address does not correspond to the installation address (only for geographic numbers)).
- The following rejection causes were created:
- Cause 311 (Number related to a Public Payphone) - according to paragraph a) of item 2 of Article 3 and with paragraph a) of item 2 of Article 13 of the Regulation;
- Cause 312 (Number related to a temporary access) - according to paragraph b) of item 2 of Article 3 and to paragraph a) of item 2 of Article 13 of the Regulation;
- Cause 315 (Capacity of the options indicated in the request is exceeded (to be eliminated on 1 January 2010)) - according to items 5 and 6 of Article 13 of the Regulation;
- Cause 313 (Document identification number does not match (not applicable to non-identified prepaid subscriptions)).
- The following rejection cause was modified:
- Cause 300 (Contract ownership does not match (not applicable to non-identified prepaid subscriptions))
- The following causes for rejection were eliminated, having been marked by marked as ''Reserved for future use'':
PT Group presented the issue, in the case of a service extinction where the company does not comply with the time limit legally established for the notice to its customers and to the regulator - 15 working days, minimum -, of it not being technically feasible to ensure full service continuity to customers with numbers from numbering blocs allocated to the company with the extinct service. In this sense, PT Group stated the importance of establishing a reasonable maximum time limit for implementing the obligation to route calls to those numbers.
ICP-ANACOM acknowledged the problem of extinction with no notice, but considered that deadlines could not be defined within the Regulation since this would disrespect the Regulation itself, since the direct routing of calls to numbers ported from blocs of the extinguished service is assumed to be made as from the extinction date advertised bye ICP-ANACOM. It also mentioned that it was each provider's service to its customers that was at stake and that service continuity is required in general and within reasonable limits, and therefore considered to be an issue upstream of portability itself.
Consequently, within the scope of the responsibilities foreseen in paragraph b) of item 1 of Article 6 of the Statutes of ICP-ANACOM, approved by Decree-Law no. 309/2001, of 7 December, and under item 2 of Article 4 of ICP-ANACOM’s Regulation no. 87/2009, we now present to the Board of Directors, for approval, the modified Portability Specification.
1 Quarantine Period - three-month period during which the customer is entitled to use the same number to the same service (at the same company or another, by requesting portability).
2 The unavailability stems from current technical constraints that may not exist when the situation occurs.
3 Services that only use the signalling network. As opposed to Call related services, based on channel switching.
4 NRN-Network Routing Number - number resulting from the concatenation of the ported number with the routing code of the company where the number is ported-in.
5 Coherent request - a set of portability electronic requests concerning several numbers or several number ranges from the same subscriber, handled as a single one, and consequently ported in the same time window.
6 The format according to this recommendation is: ''89351xydddddddddddd''.
