ImageVerifierCode 换一换
格式:PDF , 页数:53 ,大小:242.47KB ,
资源ID:541153      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-541153.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ATIS 0410500-0004-2007 Operations Administration Maintenance and Provisioning (OAM&P) -- Model for Interface Across Jurisdictional Boundaries to Support the Local Service Inquiry F.pdf)为本站会员(刘芸)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

ATIS 0410500-0004-2007 Operations Administration Maintenance and Provisioning (OAM&P) -- Model for Interface Across Jurisdictional Boundaries to Support the Local Service Inquiry F.pdf

1、 i ATIS-0410500-0004 UOM-LSR Operations, Administration, Maintenance, and Provisioning (OAM b) Interexchange Carrier Network; c) End User Network; or d) Some combination of the above. 3.4 provider: The provider is anyone who offers a standard interface to allow network management across jurisdiction

2、s of telecommunications services (or resources) they provide. 4 Acronyms Assign, reserve, or cancel a telephone number(s); Verify feature/service or Inter/IntraLATA provider availability or Code Inquiry; Schedule, reserve, or cancel an appointment; Identify service configuration; Qualify, reserve, o

3、r cancel reservations of loop facilities; and Verify the status of a facility assignment at a collocation arrangement. The following clauses are summarized from the requirements identified by OBF and documented in ATIS-0405122-0011. The functions defined in ATIS-0405122-0011 consist of the following

4、: Customer Service and Directory Inquiry The following clauses are summarized from the requirements identified by OBF and documented in ATIS-0405111-0011. The functions defined in ATIS-0405111-0011 consist of the following: Directory Listing Inquiry The following clauses are summarized from the requ

5、irements identified by OBF and documented in ATIS-0405124-0011. The functions defined in ATIS-0405124-0011 consist of the following: Loss Alert and Transition Information NOTE 1 - Valid entries and combinations per inquiry are generic and may have different interpretations in different jurisdictions

6、. NOTE 2 - This model specification adheres strictly to ATIS/OBF Local Service Ordering Guidelines. The specific input/output fields per transaction can be further refined based on provider/customer negotiations. NOTE 3 - Annex A provides the functional map of the OBF data elements to the CORBA IDL

7、contained in this standard. The following clauses are summarized from the requirements identified by OBF and documented in ATIS-0405119-0011. The functions defined in ATIS-0405119-0011 consist of the following: Service Order List Service Order Detail Service Order Activities Issued 10/16/2006 ATIS 0

8、410500-0004 6 5.1 Address Validation This function provides the customer the ability to validate the address given by the end user. The provider can indicate to the customer if there is a match, or if an alternate address exists for the customer to choose. If there is a match, the response may conta

9、in address specific information - e.g., Local Service Office (LSO), Working Telephone Number (WTN), Working Service on Premises Indicator (WSOPI), Local Service Termination (LST), Class of Service (CS). The input for address validation will be either address data or WTN, but not both. The inquiry ad

10、dress format may be fielded or concatenated. The address format received on the response may be different from what was sent on the inquiry. The response address format may be fielded or concatenated. The Local Service Request (LSR) requires parsed address fields. When parsing a concatenated address

11、 to be used on the appropriate forms of the LSR, no changes should be made, other than separating data elements into address components. The returned address should be a valid address to be used for the ordering process. When an address is sent on the inquiry, the “042 - Exact Address Match Found” r

12、esponse indicates that the inquiry address data can be used on the LSR. When an address is sent on the inquiry, the “003 - Address Match Found” response indicates that the address on the inquiry matched a service providers address data for an end user, but may differ from what was sent on the inquir

13、y (e.g., Avenue of the Americas may have been changed to 6th Avenue). For the “003 - Address Match Found,” it is the address data from the response transaction that should be used to populate the service address on an LSR. When an address is sent on the inquiry, the “005 - Address Near Match Found/A

14、lternatives Provided” response indicates the customer may choose an address from the alternate addresses provided. When alternate addresses are returned, each alternate address returned will contain all fields needed to submit a new address validation inquiry. Multiple iterations of random fields wi

15、ll not be returned on address validation responses. The customer will then submit a new address validation inquiry to obtain an “003 - Address Match Found” or “042 - Exact Address Match Found” response. When an address or WTN is sent on the inquiry, the “004 - Address Match Found - Location Informat

16、ion Required on Order” response indicates that no further validation can occur in pre-order but secondary address information is required on the LSR. When an address is sent on the inquiry, the “022 - Partial Match Found-Additional Location Information Required” response indicates that further valid

17、ation in pre-order can occur and alternatives may be provided. In both instances the “location information” refers to secondary address information such as building, room, or floor. 5.2 Telephone Number Assignment This function provides the ability for the customer to request and reserve a telephone

18、 number(s), and assign that number to an end user. The process to identify and reserve telephone numbers may vary among providers. The following clauses explain the two most commonly used processes. 5.2.1 Telephone Number Assignment Process Inquiry and Reservation Transaction: For telephone number a

19、ssignment using the one step process, in one transaction, the inquiry will specify the telephone number(s) attributes being requested. On the response, the telephone number(s) will be returned, and there is no need to have a separate transaction that will select and/or reserve the telephone number(s

20、). Issued 10/16/2006 ATIS 0410500-0004 7 This process is used by those providers that will hold the assignment of the returned telephone number(s) on the response transaction for some specified period of time. That period of time may vary by provider. If the customer does not have a need for the ass

21、igned telephone number(s), the customer is responsible for canceling the reservation of the telephone number(s). 5.2.2 Two Step Telephone Number Assignment Process For telephone number assignment using the two step process: Inquiry Only Transaction: In one transaction, the inquiry will specify the t

22、elephone number(s) attributes being requested. On the response, a list of the telephone numbers that meet the specifications and are available for assignment will be received. Some providers may temporarily hold the telephone numbers based strictly on the telephone number inquiry process. This perio

23、d of time may vary by provider. Reservation Only Transaction: A second transaction is required to reserve or hold the telephone number(s). The provider will hold the assignment of the reserved telephone number(s) for some specified period of time. This period of time may vary by provider. If the cus

24、tomer does not have a need for the reserved telephone number(s), the customer is responsible for canceling the reservation of the telephone number(s). 5.2.3 Telephone Number Assignment Criteria Telephone numbers are assigned based on location. Location criteria for telephone number assignment may in

25、clude valid service address, LSO, or LST. At least one of these criteria must be populated on the inquiry transaction. If multiple iterations of the REQNUM field are present on an inquiry transaction and one or more of those requested numbers is not valid for the location specified, the entire trans

26、action may error. 5.2.4 Cancel Telephone Number Reservation A cancel telephone number reservation transaction is expected if a reserved telephone number will not be used. Once an LSR is sent for the reserved telephone number(s), a cancel telephone number reservation transaction should not be used. I

27、f all reserved telephone numbers associated with a Response Identifier (RESID) are to be cancelled, the RESID field may be adequate to cancel the reservation. For a partial cancellation, only those numbers that need to be cancelled should be supplied in the REQNUM field. When the RESID field is popu

28、lated on the inquiry, the “029 Reservation Not Found” response indicates that no telephone number reservations have been cancelled. When the REQNUM field is populated on the inquiry and the “029 Reservation Not Found” response includes all requested numbers in Telephone Number Response (TNRES) field

29、s or no TNRES fields are populated, this indicates that no telephone number reservations have been cancelled. When the REQNUM field is populated on the inquiry and the “043 Partial Reservation Not Found” response includes a partial list of requested numbers in TNRES fields, this indicates that the n

30、umbers returned have not been cancelled. Issued 10/16/2006 ATIS 0410500-0004 8 5.3 Feature/Service Availability This function identifies those features/services that providers currently offer based on a location. The location information that may be used for feature/service availability is LSO, LST,

31、 NPA/NXX or fielded service address. The location information should have been validated prior to use on a feature/service availability inquiry transaction. Code Inquiry provides the ability to retrieve the description of a requested code appearing on a service order and the specific section in whic

32、h it will appear. Specific features or services may be identified by using the Feature Availability (FETAVA) field and/or a combination of the Network Channel Code (NC), Network Channel Interface Code (NCI) and Secondary Network Channel Interface Code (SECNCI) fields. Leaving the FETAVA, NC, NCI, an

33、d SECNCI fields blank indicates a request for all available features and services. When requesting all available features and services that can be offered at a location, the location is limited to LSO or LST. This function allows the customer to: Query for availability of specific features and servi

34、ces at a particular location. Query for available features and services that can be offered at a location. Query for available InterLATA and IntraLATA providers that can offer service at a location. Query for a description of a USOC, FID, TCIF maintained EDI codes or ISDN Ordering CODES (IOCs). The

35、availability of multiple features may be requested by populating multiple instances of the FETAVA field or by not populating the FETAVA field. The response to an inquiry that contains multiple instances of the FETAVA field shall include a Feature/Service Response (FRESP) field for each FETAVA field

36、presented. In addition to the FETAVA and FRESP fields contained in the response, when the value of the FRESP field equals “C” (Pending) or “E” (Alternate LSO Available), additional qualifiers may be returned for each FETAVA field. When the FRESP field is populated with “C,” this denotes that the fea

37、ture/service may not be available to the customer until a future date. This date may be returned using the Relief Date (REFD) field. To communicate the anticipated relief date for a particular feature/service, the response includes: The FETAVA field populated with the requested feature/service; The

38、FRESP field populated with “C”; and The REFD field populated with the anticipated relief date for that feature/service. While the same relief date may apply to multiple FETAVA fields in the inquiry, each FETAVA field in the response is paired with its own FRESP field and REFD field. When the FRESP f

39、ield is populated with “E,” this denotes that the feature/service is not available at the specified location, but is available at one or more alternate LSO(s) that serves that location. This alternate LSO information is returned using the Alternate LSO (ALTLSO) field. To communicate the alternate LS

40、O(s) for a particular feature/service, the response must include: The FETAVA field populated with the requested feature/service; The FRESP field populated with “E”; and One or more iterations of the ALTLSO field for that feature/service. Issued 10/16/2006 ATIS 0410500-0004 9 When the ALTLSO field is

41、 populated, it is recommended that a new inquiry be initiated using the ALTLSO(s) to confirm availability of all features and services being requested. While the same alternate LSO(s) may apply to multiple FETAVA fields in the inquiry, each FETAVA field in the response is paired with its own FRESP a

42、nd ALTLSO fields. For those companies that can distinguish between Inter/IntraLATA providers serving business or residence markets, the Type of Service (TOS) field must be populated when requesting the Inter/IntraLATA availability. The output would reflect those providers serving that specific marke

43、t. 5.4 Appointment Scheduling This function identifies if a dispatch to the end users location is necessary, and to establish appointment date/time. This enables the customer the ability to query for the next available appointment or a particular date for service at the end users location. If the cu

44、stomer wishes to retrieve the earliest available appointment, the Appointment Request Date (APPRD) field may be set to the date of the request or left blank. Some providers require the associated telephone number(s) on the appointment scheduling inquiry. If the telephone number is new, the REQNUM fi

45、eld is populated. If the telephone number exists, the WTN field is populated. Both fields may be populated on the same inquiry (e.g., a new line installation and changes to service on an existing telephone number). For some providers to determine if a dispatch is necessary, a list of the features/se

46、rvices being requested must be sent on the inquiry. If there are multiple lines associated with this inquiry, the FETAVA field should be an aggregation of all features. There is no need to distinguish features at a line level. The Dispatch Indicator (DSIND) field may be used to indicate if a dispatc

47、h is necessary to the end users premise. When the Appointment Response Date (APPRES) field is not returned, then provider-supplied intervals may be used to establish a due date(s). 5.5 Appointment Reservation This function is used to reserve or hold an appointment date/time obtained in a previous ap

48、pointment scheduling response. The length of time that the reservation is held varies by provider. If the date/time requested is not available, a list of alternate dates and times may be returned. To reserve any one of these alternate dates and times, a new scheduling reservation transaction may be required. 5.6 Cancel Appointment Reservation A cancel appointment reservation transaction is expected if a reserved appointment will not be used. To cancel an appointment reservation the RESID field must be populated. 5.7 Service Configu

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1