WO2001093622A1 - Mise a jour de numero d'identification personnel - Google Patents

Mise a jour de numero d'identification personnel Download PDF

Info

Publication number
WO2001093622A1
WO2001093622A1 PCT/US2000/014859 US0014859W WO0193622A1 WO 2001093622 A1 WO2001093622 A1 WO 2001093622A1 US 0014859 W US0014859 W US 0014859W WO 0193622 A1 WO0193622 A1 WO 0193622A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
pum
personal identification
identification number
call
Prior art date
Application number
PCT/US2000/014859
Other languages
English (en)
Inventor
Peggy M. Stumer
Dennis L. Kucmerowski
Original Assignee
Siemens Information And Communication Networks, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/580,275 external-priority patent/US6760585B1/en
Application filed by Siemens Information And Communication Networks, Inc. filed Critical Siemens Information And Communication Networks, Inc.
Publication of WO2001093622A1 publication Critical patent/WO2001093622A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support

Definitions

  • the present invention relates to voice, multi-media, video and data services which span and interwork across an intelligent (e.g., ISDN, IN, Internet) network.
  • the network can span the public network (e.g., CSIG at C reference point), private networks (e.g., QSIG at Q reference point), and interwork between public and private networks.
  • This invention is applicable to ISO/ECMA QSIG compliant ISDN Private Integrated Services network (PISN) Inter-Exchange Signalling Protocol - Private User Mobility (PUM) Registration Supplementary Service and Call Handling Additional Network Features.
  • PISN ISDN Private Integrated Services network
  • PUM Inter-Exchange Signalling Protocol - Private User Mobility
  • PUM Private User Mobility
  • ISO/IEC DIS 17878 PISN - Inter-exchange signalling protocol - Private user mobility (PUM) - Call handling additional network features (ECMA 284) - provide network signalling for a mobile user, including registration, activation/deactivation, interrogation, and call handling (e.g., diverting an incoming call from the home PINX to the PINX where the PUM user is located).
  • PIN is only included in the standards registration, deregistration and interrogation signalling. Update procedures and signalling mechanisms do not currently exist for changing the PIN during an active call. Thus, there is a need for such update and signalling mechanisms that do not exist in the draft standards as listed above.
  • PUM has been implemented previously by vendors in a single system where users may re-locate anywhere within the same system. This system feature does not require a PUM number or Al since the visitor device and PUM user/HDM is still within the local system which performs PUM registration, de-registration, and other PUM-related services based on a user's PIN.
  • the ISO/ECMA PISN PUM draft standards provide an alternate means for network PUM registration where the user enters an alternative identifier rather than the PUM number. This adds an additional level of validation checking for registration.
  • the mechanism to translate the alternative identifier to an address that can handle the particular user registration is not defined. Because the draft standard has not been approved as of this writing, no known vendor has implemented the alternative identifier translator. Thus, there is a need to provide a mechanism to translate the alternative identifier as discussed.
  • This invention describes update mechanisms comprised of signalling and a service elements to change a PIN value associated with an active call. It describes a procedure associated with the update mechanism which can be implemented as an additional procedure to the QSIG Private User Mobility (PUM) supplementary services.
  • PUM QSIG Private User Mobility
  • This invention is not limited to a QSIG private network, rather, it could apply to a QSIG at the public network reference point C (i.e., CSIG), TCP/IP, CSTA protocols, etc. '
  • an update procedure uses existing PUM registration to validate/authenticate the new/modified PIN entered by a PUM user, provides out-of-band/D-channel signalling for changing a PIN value during active call state, update procedure with service elements including (but not limited to) change type and the new PIN value, and matching call detail recording by PIN value (optionally) at each PINX in the call path as a result of honoring the Update procedure.
  • the CDR update procedure may be ignored at other systems/servers that receive the PUM-Update invocation request.
  • the PUM user's session at the Visited PINX may optionally revert back to the originally registered PIN value (stored), or, may continue the PUM user's session using the last entered PIN value, for example, based on an administrative parameter(s) or fixed as an implementor's choice.
  • a mechanism to translate the alternative identifier to an address that can handle the particular user registration is disclosed.
  • the PP-AIT includes a software translator mechanism with various implementation options, for mapping an alternative identifier to a translated number representing the Home PINX of the particular PUM user and returning either a rejected result or accepted result with the Home PINX address which is used for subsequent registration, de-registration and other processes (e.g., interrogation).
  • PP-AIT optionally facilitates the registration process on behalf of the requesting PINX (i.e., Visitor PINX) effectively performing both first and second level security validations and returning either a rejected result or accepted result with the PUM number.
  • This control of the signalling is beyond what the standards have identified but is significant since it circumvents the signalling of the Enquiry (i.e., PISN-ENQ) information flow but is still ISO/ECMA compliant signalling.
  • PP-AIT has the following capability:
  • the Alternative Identifier can be translated to a network routable address that can register the particular PUM user and provide subsequent services such as redirecting this user's incoming calls to the visited remote location.
  • This invention provides a detail description of the translation process to the appropriate network routable address for this PUM user. It also enhances the function whereby PUM registration permission is optionally based on day of year, time of day.
  • the standards bodies have allocated the translation mechanism to a Directory PINX only. This invention allows for the translation mechanism to be located anywhere in the network, in multiple PINXs and even outside the presence of a directory PINX.
  • this invention provides an alternative way to circumvent and reduce the ISO/ECMA defined signalling (i.e., without changing the signalling, only eliminating potentially unnecessary signalling reducing overall network traffic on the D-channel), transparent to the network.
  • the signalling is ISO/ECMA compliant and therefore compatible with any other ISO/ECMA compliant vendor's product.
  • FIG. 1 is a block diagram of the PUM-Update major components/modules in accordance with the present invention.
  • FIG. 2 is a detailed block diagram of PUM-Update procedure and logic in accordance with the present invention.
  • Figure 3 is the a table of the PUM-Update service element contents in accordance with the present invention.
  • Figure 4 is an example of PUM-Update ASN.l encoding.
  • Figure 5 is the ISO/ECMA functional model comprised of the PUM functional entities; specifically, the present invention performs FE8 translator functions and can control registration signalling on behalf of Visitor PINX.
  • Figure 6 is a detailed block diagram of PP-AIT with the translator function returning a Home PINX address in accordance with the present invention.
  • Figure 7 is a detailed block diagram of PP-AIT with the translator function and the ability to control the registration signalling on behalf of Visitor PINX returning the PUM user's PUM number in accordance with the present invention.
  • Figure 8 is an example Translator table depicting PP-AIT address resolution.
  • Figure 9 is an example Translator table where multiple PP-AITs exist in the network.
  • Figure 10 is a SDL description for the PP-AIT mechanism when a PISN-ENQ is received with an AL
  • Figures 11a and 1 lb are SDL descriptions for PP-AIT at a Visitor PINZ where a user has entered a PIN and Al to be registered as a PUM user; and when a PUM-R is received with an Al and PIN respectively.
  • Active call The term "active call” in this disclosure includes other states that can be reached following through-connection (i.e., beginning with sending the Connect message) such as consultation hold, park, conference, etc. Which specific states to allow PUM-Update is an implementor's choice.
  • An alternate identifier may be entered by the user instead of entering a PUM number.
  • the Al must be translated to an address that can register the particular user and perform services for the remote user.
  • the alternate identifier translation result represents the user's Home PINX address and need not be unique.
  • the Home PINX address is used to complete registration and other services (e.g., redirect the PUM user's incoming calls to the visited PINX) provided by the Home PINX for its PUM users.
  • APDU Application Protocol Data Unit
  • CDR Call Detail Recording
  • Destination PINX The PINX of the called user.
  • a destination PINX may also be a Visitor PINX serving a called PUM user.
  • Directory PINX PINX where ISO/ECMA has defined FE8 is located in the network.
  • FE ISO/ECMA functional model comprised of Functional Entities (FEs 1 through 8) which provide the services and signalling of PUM.
  • Gateway An entry-point PINX or end-point PINX providing protocol conversion/interworking (e.g., between non-QSIG and QSIG, public network and private network).
  • HDB Home Data Base
  • Home PINX The PINX that has local access to the HDB entry for a particular PUM user.
  • Modify PIN/CDR This type of change indicates that the call detail recording record should overwrite the existing PIN value with the modified PIN value received.
  • New PIN/CDR This type of change indicates that the call detail recording record should be closed and a new one opened with the new PIN value.
  • PP-AIT The software mechanism described in the present invention which translates the Alternative Identifier value and returns the PUM user's Home PINX address. Optionally, it may complete the registration function (i.e., PUM-R) on behalf of the Visitor PINX and return the user's PUM number.
  • PUM-R Registration function
  • PINX Private Integrated Services Network Exchange (ECMA 133); applies to the terms "system/server” as well.
  • PISN Private Integrated Services Network (ECMA 133)
  • PIN Personal Identification Number (unique string typically comprised of digits) assigned to the particular PUM user.
  • a PUM user may have more than one PIN assigned depending on the particular application of PIN.
  • PUM Private User mobility
  • PISN-ENQ Confirmed information flow used to request/ENQuiry the PUM number for a PUM user identified by an alternative identifier.
  • PUM Number The particular user's unique address/identity used, for example, to route a registration request to the Home PINX for validation.
  • PUMX Refers to either a PUMO or PUM.
  • PUM-R Confirmed information flow that is used to request a PUM Registration upon a PUM user invoking registration at a visited terminal/PINX.
  • PUM user A registered mobile user currently located at a Visitor PINX. Also, a particular mobile user with FE1 and FE2 user functions currently located at a Visitor PINX.
  • VDB Visitor Data Base
  • Visitor PINX A PINX serving the PUM user invoking PUM functions (e.g., registration, PUM- Update). Also, a PINX with FE3 and FE4 functionality serving the PUM user invoking PUM functions (e.g., registration). FE2 receives a PUM-DR1 from FE1. FE2 communicates directly with FE4 and FE8.
  • the present invention relates to a system for enabling the PUM supplementary telecommunication service functions, in particular, an update procedure in a communication network having a plurality of interconnected PINXs which enables a mobile user to change the PIN value associated with a particular active call without disruption of the bearer channel.
  • a PUM user may change the PIN.
  • the PUM user's session at the Visited PINX may optionally revert back to the originally registered PIN value, or, may continue the PUM user's session using the last entered PIN value (implementor's choice).
  • the types of changed PIN (and CDR) include:
  • Both the calling and called user may be PUM users.
  • PUM users may invoke the PUM Update operation.
  • Administrative parameters may be used at each system/server involved in the call path to determine whether it should honor or ignore the PUM update operation.
  • Each system/server in the network may be capable of CDR.
  • a system/server receives a PIN in a SETUP message, it is recorded in each CDR record (i.e., one record per call) ⁇ even at transit system/servers.
  • a PUM user registers with a PUM number and/or alternative identifier and PIN. The PIN is delivered over the network during setup establishment (e.g., SETUP message) of an outgoing call.
  • PUM-Update permits sending a PIN value into the network beginning with the Connect message to the calling party's PINX.
  • each system/server in the connection may record the PIN in its CDR.
  • the CDR records generated for a private network are commonly collected from each system/server and sorted (i.e., including a sort field on PIN) so that all the CDR records for a particular call are together for accounting/charge-back to a person or account for billing reasons.
  • PIN is used as an account code (e.g., many PINs to many PUM users relationship, not one-to-one)
  • PUM users may need to change the PIN multiple times during one call. For example, two attorneys discussing first, case A, then case B and lastly case C during one call. A PIN is entered initially during setup establishment (by an attorney) for the duration of case A discussions, then the PIN value is changed (by an attorney) at the beginning of discussions on case B, and the PIN value again changed (by an attorney) at the beginning of discussions on case C.
  • the update of the PIN value is sent into the network over the D-channel.
  • Each system/server in the call path may optionally act on the update information by closing the existing CDR record, then open a new record with the "new" PIN value. Subsequently, there will have been 3 CDR records (with PIN values for case A, case B and case C) recorded at each system/server (i.e., assuming they are acting on the update information) for this one call.
  • the calling and called users may be PUM users and can both change the PIN value during the call. This is one reason why each system/server in the call path may optionally act on the update information. Administrative parameters may be implemented to control what the system/servers should do in this case (e.g., destination system/servers records its PUM user's PIN values, originator system/servers records its PUM user's PIN, and transit system/servers record only originator PUM user's PIN values).
  • FIG. 1 illustrates a block diagram of the major components and signalling involved in the PUM- Update mechanism in accordance with this invention.
  • the diagram represents a call example where a PUM user makes an outgoing call from the Visitor PINX (1) and is routed via Transit PINX (3) to its destination in Any PINX (5).
  • PUMO (7) and PUMI (8) exist for PUM call handling.
  • PUM-Update 9 is activated.
  • the Change Pin process (15) detects whether a "new" or “modify” request was entered by the user (e.g., via key depression) and stores the request along with the subsequent PEN value entered by the PUM user.
  • the PIN value must be validated and or registered. This is accomplished via calling the PUM-R and/or PISN-ENQ processes (17) which sends a confirmed request on a call-independent connection
  • PUM-Update will send (19) a PUM-Update invocation (21) in a NOTIFY or FACility message on the D-channel of the active connection.
  • This request may be sent (i.e., pumo) indicating a return result, shown as (22), is requested or it may be sent without confirmation (i.e., implementor's choice).
  • PUM-Update operation functions identically from the destination PINX on an incoming connection (i.e., pumi).
  • PUM-Update 11 and 13 components are activated.
  • the PUM-Update request is acted on according to the PINXs administrative parameter(s).
  • the PUM-Update modules for Change PIN and Call PUM-R or PISN;J ⁇ NQ functions are not needed.
  • the inset (13) illustrates the transit PINX PUM-Update module comprised of receiving a Pumx-Update invocation (12 and 14) from either or both directions receive paths, optionally acting on "new" or "modify” actions pertaining to CDR based on administrable parameter(s).
  • the Visitor PINX upon receiving the return result may act accordingly (e.g., mark the CDR record with an imprecise data flag indicating CDR records may not match across the network).
  • Figure 2 represents the Specification and Description Language (SDL) for the PUM-Update procedure for both the Visitor PINX and the destination PINX either of which may have a PUM user connected with the active call (30), that is, an active call state reached via a Connect message.
  • PUM-Update is idle (33) until either a PUM user enters a change PIN/CDR invocation with a PIN value (35), or, when a Connect, Facility or Notify message with PUM-Update invocation is received (51).
  • SDL Specification and Description Language
  • the PIN value Upon receiving a "new" or “modify” CDR request from the PUM user, the PIN value should be validated even when the PUM user has already registered with a different PIN. As one alternative choice, some high priority PUM users may have reserved PIN values that exempt it from such validation. A PUM user may use more than one PIN value depending on the application.
  • a Facility message with a PUM-R req.ind (and/or PISN-ENQ when the PUM user has an alternative identifier) is sent to the PUM user's Home PINX in order for the PIN value to be validated.
  • a return response (41) indicates whether or not the PIN value has been validated.
  • an error indication (e.g., display) is sent to the user (43). Otherwise, upon acceptance, a pumxUpdate.inv (45) is sent to the other end of the connection. It may be sent in a Facility message when a return result is requested, or, in a Notify message when no return result is required.
  • the Visitor PINX shall interface with CDR (48) by sending an internal message (or other implementation) in order to act on the change request, either:
  • the Visitor PINX shall wait for the response. If no response is received before time-out, the message may be resent (i.e. implementor's choice). If the return result was negative (e.g., not implemented), the Visitor PINX may elect to denote in the CDR record that network records may be imprecise. The PUM-update procedure returns to idle, but, may be re-activated at any time during the call duration. Still referring to figure 2, when a PINX receives a pumxUpdate.inv (51), it shall determine whether to act on it according to its local administrative parameter (55).
  • step (61) If yes, then indicate the action (i.e., "new” or “modify” CDR) to the CDR procedure (57). If no, go to step (61). If the PINX is an end-point (i.e., Visitor or Any PINX that is not a transit) and a return result was requested, a Facility message with the appropriate result shall be returned to the sender (61).
  • end-point i.e., Visitor or Any PINX that is not a transit
  • FIG 3 shows one embodiment of the contents of the PUM-Update invocation (pumxUpdate.inv).
  • the PUM user's Identity (65) is used to identify the PUM user. It is a mandatory service element.
  • the Hosting Address (67) is the Visitor PINX network address and is a mandatory service element.
  • Service option (69) has two possible values: 1) "new" PIN/CDR indicates to the receiving PINX(s) that the current CDR record shall be closed and a new CDR record opened using the new PIN value, 2) "modify" PIN/CDR indicates that the current CDR record shall overwrite the existing PIN value with the modified PIN value.
  • the new/modified PIN value is sent in service element (71) and is mandatory.
  • a PIN value of zero may be considered valid (i.e., implementor's choice) and could have special meaning of "no PEN".
  • the PIN may or may not be validated (e.g., PUM user with designated priority to use no/zero PIN without validation).
  • Request result (73) indicates to the end-point receiving PINX that it must return a result indication (i.e., ACK, Invalid/error, Not implemented) in a Facility message. This service element is optional, but a response will not be sent if not requested.
  • Figure 4 provides one embodiment of the ASN.l for the PUM-Update operation.
  • This code effectively extends the ISO/ECMA ASN.l PUM operations to include the PUM-Update operation and is therefore, not stand-alone code. It has just been shown a mechanism for updating a PUM users PEN at various points in a network.
  • the present invention contemplates all obvious variations to the particular embodiments disclosed herein.
  • This mechanism also relates to a system for enabling the PUM supplementary telecommunication service functions, in particular, the translation of a PISN PUM alternative identifier supplementary service in a communication network having a plurality of interconnected PINXs which enables mobile users to temporarily relocate to a remote/visitor PINX in the network.
  • FIG. 5 illustrates the ISO/ECMA functional model in an interconnected private network system.
  • the following ISO/ECMA functional entities (FE) are provided as informational only:
  • a PUM user i.e., FE1 and FE2
  • a Visitor PINX serving the PUM user
  • VDB i.e., FE3 and FE4
  • PP-AIT which may reside in any PINX(s) in the network (i.e., FE8 plus additional functionality), and a Home PINX serving the PUM user's static residence and HDB (i.e., FE5).
  • PP-AIT can be centralized or distributed in the network i.e., at a single PINX in the network (e.g., ISO/ECMA specify FE8 located at a single directory PINX in the network), or at selected PINXs in the network (e.g., network hub PINXs), or at all PINXs in the network (in this case PISN-ENQ signalling is purely an internal interface).
  • PISN-ENQ signalling is purely an internal interface.
  • Two signalling options are supported by PP-AIT and are described in figure 6 (using PISN-ENQ) and figure 7 (using PUM-R).
  • One or both options may co-exist in PP-AIT since both are mutually exclusive. The implementation option selected may conserve on network resources and D-channel traffic depending on the particular network topology and configuration. Both PISN-ENQ and PUM-R signalling are call independent signalling connections, therefore, bearer channel connections through the network are not impacted.
  • Both diagrams in figures 6 and 7 include functions found in the Visitor PINX, PP-AIT (at any PINX) and the Home PINX. The focus is on the functions of PP-AIT in accordance with the present invention. PP-AIT functionality could be located in the PINX of both or either Visitor PINX and Home PINX or could be in a separate PINX. This is true for both signalling options.
  • the Visitor PINX When the Visitor PINX receives an alternative identifier (e.g., PumRegistrArg ⁇ alternativeld ⁇ ) entered from a PUM user, the Visitor PINX must know the address where PP-AIT resides (i.e., same PINX or another PINX) which is typically administered in its local database. Likewise, any FE2 and FE4 in the network must know the address of PP-AIT in order to send a PISN-ENQ to obtain the translated number.
  • an alternative identifier e.g., PumRegistrArg ⁇ alternativeld ⁇
  • PISN-ENQ Enquiry Logic and Signalling
  • the Visitor PINX [605] sends a PISN-ENQ request [610] to PP-AIT [615] with a PISN-ENQ receive/send response component [617], (PP-AIT functions are located in the dashed box) which provides only the translation function and if translation is successful, returns accepted and a Home PINX address to the Visitor PINX, otherwise a rejection is sent.
  • PP-AIT functions are located in the dashed box
  • This is the first level security pass adherent in a network employing alternative identifiers.
  • This translator functionality and signalling is compliant with the ISO/ECMA standards.
  • PP-AIT upon receiving a PISN-ENQ request, shall process [620] the request by looking up the received alternative identifier value in its local Translator Table [625].
  • An example Translator table is provided in figure 10. If the Al value is not found, PP-AIT returns a response result [630] of "rejected" to the Visitor PINX (and subsequently FE1). If the Al value is found, the corresponding Home PINX address assigned to the Al is returned in the response service element "PUM number" and an "accepted” result is indicated. This completes PP-AITs translation function for a PISN-ENQ. The Visitor PINX indicates to its PUM user that registration failed [635] if the returned result is rejected.
  • the Visitor PENX then sends a PUM-R request [640] to the Home PINX [645] which validates [650] the PIN received in the PUM-R (second security level) and returns [655] either registration acceptance with the user's PUM number, or, registration rejection to the Visitor PINX.
  • a PISN-ENQ may be sent (from either FE2 or FE4) to PP-AIT for other services such as de- registration and interrogation and PP-AIT honors the request and returns a result.
  • the PUM user's number is known and can be saved and used for other services rather than translating the alternative identifier again.
  • the Visitor PINX [700] receives a PUM-R request [705] with Al and gives control to its PP-AIT PUM-R send component [710] (special PP-AIT processing in the Visitor PINX) which tandems the PUM-R request with Al (in accordance with the present invention) to the PP-AIT PUM- R receive component [715]. Tandeming the PUM-R replaces sending a PISN-ENQ to PP-AIT and Visitor PINX [725] subsequent registration processing. This mechanism is not included in the ISO/ECMA standard although the signalling is entirely compatible with the draft standards.
  • PP-AIT (as shown within the dashed box [720]) includes both components PUM-R send/receive response [725] and PUM-R receive/send response [723].
  • the diagram depicts the PP-AIT send PUM-R/receive response component [725] in a separate PINX from the PP-AIT receive PUM-R/send response component [723] although both could reside in the same PINX.
  • PP-AIT sends the received PUM-R message [740] to the Home PINX [745].
  • the PUM-R does not include a result or PUM number (sent as received) service elements in the direction to the Home PINX.
  • PP-AIT shall adhere to ISO/ECMA timers, exception handling, etc. associated with sending a PUM-R request.
  • PP-AIT receive response [760] also tandems the PUM-R response back to the requesting FE.
  • PP-AIT, with this signalling option effectively brokers or acts as an agent for the Visitor PINX possibly saving time and network resources.
  • PP-AIT can therefore be a transparent process in the network while eliminating the PISN-ENQ signalling.
  • the example Translator table requires 2 columns i.e., Al value [800] and Home PINX address [805] and may optionally have other fields.
  • an additional field to store an index [810] to a time schedule table e.g., Julian date 000-365 by 00:01 to 24:00 hour ranges
  • PP-AIT shall accept or rej ect the PISN-ENQ or PUM-R based on the time of day/day of year as compared with the indexed time schedule table.
  • the description field is not used by PP-AIT, it is only a comment field for the network administrator. It is recommended that the table be kept in sorted order by Al value and that binary searches are used to match the received Al value to an Al value in the Translator table.
  • a PP-AIT requirement is that the Home PINX address assigned to an Al value in the Translator table be a routable address in the network to the PUM user's Home PINX.
  • Al values need to be pre-defined and assigned to PUM users.
  • An Al value may be assigned to one or many PUM users i.e., it need not be unique to one user in accordance with the present invention, in fact it is recommended there be a limited number of Al values per Home PINX in order to decrease processing time. " All PUM user's having the same Al value (unknowingly) must be residents of the same home PINX.
  • the ISO/ECMA standard has defined the Al as an octet string of 1-20 bytes. It is recommended in accordance with the present invention that Al values have a short length to limit the number of digits dialed by the PUM user during registration. It is required that each PINX have one or more unique AIs. For example, in a network of 75 or fewer PINXs (leaving room for growth) where only one Al value addresses one PINX, an Al length of 2 digits is sufficient (i.e., values 0-99). Another example, in a network of 25 PINXs where each Home PINX supports 4 different Al values, a 2-digit Al length leaves no room for future growth since all 100 values would be assigned. In this case, a maximum Al length of 3-digits is needed (unless the particular network is expected to decrease in PINXs).
  • the example illustrates Al values 10, 11, and 12 that route to the same Home PINX (i.e., PINX-US) using the same address 100-1000.
  • Al value 20 routes to one Home PINX (i.e., PENX-Japan).
  • Al values 30 and 31 both route to the same Home PINX (i.e., PENX-UK) but using two different Home PINX addresses.
  • Al value 40 and 45 are mapped to a Home PINX of "home”. This indicates that PP-AIT is located either in the same PINX as the invoking PUM user or the Home PINX for this PUM user is the PINX with PP-AIT.
  • network registration is purely a local process.
  • PP-AIT could return either the PUM user's number or the Home PINX address in a PUM-R or PISN-ENQ.
  • a field is designated for a time schedule index [810].
  • PP-AIT finds a matching Al value in the Translator table as was received in a PISN-ENQ or PUM-R, it shall use the index into a time schedule table (not depicted) which indicates, for example, the day of year/time of day access permission (i.e., access allowed or disallowed).
  • Figure 9 is an example of a Translator table in another PENX (i.e., PENX-UK) when multiple PP- AITs are configured in the network (where Figure 8 is in the same network as Figure 9).
  • the Home PINX address is "home" for both Al values 30 and 31 and Al value 40 and 45 have the PINX-12 address (i.e., 400-4000). This reflects the different PINX frame of reference as it regards to the Translator table Home PINX addresses.
  • FIG 10 illustrates a Specification Description Language (SDL) for PP-AIT [1000] when a PISN- ENQ is received with an Al [1003].
  • PP-AIT shall use the Al to search its translation table [1005] for an identical matching entry [1007]. If no matching Al value is found, a return result of rejection shall be sent [1009] to the Visitor PINX. If a matching Al value was found, the associated index (when employed) is used to lookup in the Time Schedule table [1011] and compare the current system day and time to the Time Schedule table entry for the allowed access days and time. If the current time falls within the permissible access time(s) [1013], a return result with acceptance and the Home PINX address is sent in the response [1015]. Otherwise, if the current time did not fall within the permissible access time(s), a return result of rejection is sent in the response [1017]. PP-AIT returns to idle state [1000].
  • SDL Specification Description Language
  • Figures 1 la at the Visitor PINX and 7b (Directory/Any PINX) provides the detail the logic of the PP-AIT PUM-R functions and signalling. This signalling option does not require a separate PISN-ENQ message sequence to translate the AL
  • Figure 11a illustrates a Specification Description Language (SDL) for PP-AIT [1100] at a Visitor PINX where a user has entered a PIN and Al to be registered as a PUM user.
  • An internal message is sent to PP-AIT which receives it [1121] and shall process it by sending the Al and PIN in a PUM-R [1123] to a Directory PINX (i.e., can reside in any PINX) in a non-call related Setup message.
  • a supervisory timer is set [1125] to monitor for a response.
  • the supervisory timer for receiving the PUM-R return result response should allow enough time for network signalling and functions of PISN-ENQ (although a PISN-ENQ is not used) and PUM-R that will be performed by the Directory PINX.
  • the supervisory timer is stopped [1129]. If the return result was acceptance, the PUM user is successfully registered and may continue with the call and PP-AIT is returned to idle state. Otherwise, if the return result was rejection, an indication of failure is returned to the user (e.g., "invalid PIN" display).
  • the timer expires [1131] before receiving a response, it is an implementor's choice [1133] whether to resend the PUM-R (e.g., retry one time) or to freat the registration as a failure and indicate this to the user and return PP-AIT to idle state.
  • PUM-R e.g., retry one time
  • Figure 1 lb illustrates a Specification Description Language (SDL) for PP-AIT [1100] when a PUM-R is received with an Al [1141] and PIN.
  • PP-AIT shall use the Al to search its translation table [1143] for an identical matching entry [1145]. If no matching Al value is found, a return result of rejection shall be sent [1147] to the Visitor PINX and PP-AIT returns to idle state.
  • the associated index (when employed) is used to lookup in the Time Schedule table [1149] and compare the current system day and time to the Time Schedule table entry for the allowed access days and time.
  • PP-AIT shall send the PUM-R (as received) on behalf of the Visitor PINX, to the Home PINX address (obtained from the Translation table).
  • a PUM-R supervisory timer is started (refer to figure 1 la for choices if this timer expires before receiving a response).
  • the Home PINX performs the validation check of the PIN and, if valid, registration is successful and returns the PUM User's number (and other pertinent information) with acceptance in a return result response.
  • the Home PINX functions are not illustrated in the SDL since they are not a function of PP-AIT and the signalling is compliant with the standards.
  • PP-AIT receives the response from the Host PINX [1157], it is transparently returned to the Visitor PINX [1159] and PP-AIT returns to idle state.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un réseau comportant des services de traitement d'appel pour usagers de téléphone mobile, des services demandés par ledit usager d'un appel actif, chaque usager s'inscrivant aux services avec un numéro d'identification personnel (PIN), et un procédé de mise à jour dudit numéro d'identification personnel pendant un appel actif. Les étapes dudit procédé comprennent l'inscription de l'utilisateur dans un premier temps au réseau pour des services associés au numéro d'identification personnel pendant un appel actif, la signalisation d'une préférence d'utilisateur pour mettre à jour le numéro d'identification personnel, et la mise à jour dudit numéro lors dudit appel actif. Selon un autre aspect, cette invention concerne un réseau pourvu de plusieurs serveurs connectés aux usagers de téléphone mobile demandant des services d'appels. Lesdits usagers s'inscrivent à un desdits serveurs avec une mobilité d'utilisateur privé, chaque utilisateur a un serveur local associé et peut demander des services au niveau dudit serveur local ou d'autres serveurs de visiteurs. L'invention a également trait à un procédé d'inscription. Les étapes de ce procédé d'inscription consistent à entrer un identificateur différent au lieu du numéro de mobilité d'utilisateur privé au niveau d'un serveur, établir une correspondance entre ledit identificateur et un numéro représentant ledit serveur local de l'usager, et retourner le résultat refusé ou accepté audit serveur local.
PCT/US2000/014859 2000-05-25 2000-05-30 Mise a jour de numero d'identification personnel WO2001093622A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/580,275 US6760585B1 (en) 1998-12-02 2000-05-25 Private user mobility (PUM) update and private integrated services network PUM alternative identifier translator (PP-AIT) system and methods
US09/580,275 2000-05-25

Publications (1)

Publication Number Publication Date
WO2001093622A1 true WO2001093622A1 (fr) 2001-12-06

Family

ID=24320433

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/014859 WO2001093622A1 (fr) 2000-05-25 2000-05-30 Mise a jour de numero d'identification personnel

Country Status (1)

Country Link
WO (1) WO2001093622A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140344166A1 (en) * 2013-05-14 2014-11-20 Mastercard International Incorporated System and method for mobile pin synchronization

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995020864A1 (fr) * 1994-01-28 1995-08-03 Telia Ab Amenagement d'un systeme de telecommunications
WO1997011443A1 (fr) * 1995-09-18 1997-03-27 Telefonaktiebolaget Lm Ericsson (Publ) Procede et dispositif pour l'authentification d'utilisateur
WO1997027716A1 (fr) * 1996-01-24 1997-07-31 Nokia Telecommunications Oy Gestion de clefs d'authentification dans un systeme mobile de communications

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995020864A1 (fr) * 1994-01-28 1995-08-03 Telia Ab Amenagement d'un systeme de telecommunications
WO1997011443A1 (fr) * 1995-09-18 1997-03-27 Telefonaktiebolaget Lm Ericsson (Publ) Procede et dispositif pour l'authentification d'utilisateur
WO1997027716A1 (fr) * 1996-01-24 1997-07-31 Nokia Telecommunications Oy Gestion de clefs d'authentification dans un systeme mobile de communications

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140344166A1 (en) * 2013-05-14 2014-11-20 Mastercard International Incorporated System and method for mobile pin synchronization
US9792607B2 (en) * 2013-05-14 2017-10-17 Mastercard International Incorporated System and method for mobile pin synchronization

Similar Documents

Publication Publication Date Title
KR100693394B1 (ko) Ｕｍｔｓ에서의 로밍 지원 방법 및 시스템
US8315593B2 (en) Method for billing in a telecommunications network
CN101416468B (zh) 通信系统中由网络发起的ims注册的方法和系统
US20080107243A1 (en) Method And Apparatus For Handling Emergency Calls
US7822416B2 (en) Methods and systems for allowing global roaming between devices supported by different protocols
JP2002512496A (ja) データネットワークを利用したインテリジェントネットワークのサービスの実施
EP1334624A1 (fr) Transmission de donnees de service
CN1390014A (zh) 在多媒体网络中的用户检验服务
WO2007003123A1 (fr) Méthode d’interrogation d’informations d’emplacement géographique et système dans domaine de paquet
KR100473607B1 (ko) 아이피 멀티미디어 홈 가입자 서버에서 가입자 프로파일구축 및 전달 방법
JP5122577B2 (ja) 通信ネットワークへのアクセス
US6810034B1 (en) Automatic conversion of telephone number to internet protocol address
US6760585B1 (en) Private user mobility (PUM) update and private integrated services network PUM alternative identifier translator (PP-AIT) system and methods
WO2001093622A1 (fr) Mise a jour de numero d'identification personnel
US6880001B1 (en) System for managing and exchanging telecommunication system subscriber data stored in a single logical subscriber database
KR100869877B1 (ko) 통합 프레젠스 서비스 시스템 및 방법
KR100392586B1 (ko) 아이피망을 이용한 일반전화기와 인터넷 전화기의 서비스 방법 및 이를 위한 인증 메시지 포맷
RU2262213C2 (ru) Способ поддержки роуминга и системы для его осуществления в универсальной сети мобильной связи (umts)
CN1972320B (zh) 分组网络获得固网接入用户终端的地理位置信息的方法
CA2403629C (fr) Procede et systeme d'etablissement de communication entre une premiere et une seconde entite de communication
WO2000074422A1 (fr) Itinerance dans un reseau mta
KR200331469Y1 (ko) 아이피망을 이용한 인터넷 전화기와 일반전화기의서비스장치
EP1155560A1 (fr) Conversion automatique de numeros de telephone en adresses ip
JP2005159582A (ja) Ｉｐ網を用いたｉｐ電話と一般電話（ｉｓｄｎ含む）間のサービス方法及びこのための認証メッセージフォーマット
KR20050079828A (ko) 계층적 구조의 문자주소를 이용한 전화통신 방법 및 그시스템

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA JP MX NO

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP