CN100459813C - Method for obtaining service failure reason in heterogeneous network - Google Patents
Method for obtaining service failure reason in heterogeneous network Download PDFInfo
- Publication number
- CN100459813C CN100459813C CNB200610072670XA CN200610072670A CN100459813C CN 100459813 C CN100459813 C CN 100459813C CN B200610072670X A CNB200610072670X A CN B200610072670XA CN 200610072670 A CN200610072670 A CN 200610072670A CN 100459813 C CN100459813 C CN 100459813C
- Authority
- CN
- China
- Prior art keywords
- failure
- affairs
- event
- mih
- entity
- Prior art date
- Legal status (The legal status 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 status listed.)
- Expired - Fee Related
Links
Images
Abstract
The key ideal of the invention is: when the bottom layer entity transaction failures, the bottom layer entity reports the failure transaction and its reason information to the upper layer entity; according to the reported information, the upper layer entity gets the failure transaction and its reason. By the invention, the upper layer entity can select appropriate processing modes according to the different failure reasons.
Description
Technical field
The present invention relates to the communications field, relate in particular to obtaining of service failure reason in a kind of heterogeneous network.
Background technology
Along with development of Communication Technique, various new network technologies constantly occur, between heterogeneous networks such as present IEEE 802.11, IEEE 802.15, IEEE 802.16,3GPP, 3GPP2, switch the quality of the time communicating by letter in order to guarantee terminal with roaming, IEEE 802 wireless working groups have set up IEEE 802 switches seminar-Handoff ECSG, and definite designation afterwards is IEEE 802.21 working groups.It can make client device best network connection type and access point of automatic selectivity price ratio when inter-network roaming or switching, and can need not realize seamless switching under the situation of user intervention, strengthen the user experience of mobile device by supporting the switching between heterogeneous network.
802.21 the realization framework of agreement is as shown in Figure 1, its coverage comprises:
1, defined a kind of mobile node (MN) can provide the transparent continuous sex service when the link layer of isomery switches framework, the mobility management protocol stack of this framework to support in the network element to switch.802.21 agreement does not comprise framework realization details and the first-selected guidance that realizes.
2, in the mobility management protocol stack, define one group and switched relevant function and new entity, i.e. media-independent handoff functionality (MIHF) entity.
3, defined extra MAC layer SAPs and relevant primitive, helped to gather link layer information and control link behavior when switching at every kind of specific access technology.
4, defined the irrelevant Service Access Point (SAPs) and the relevant primitive that inserts MIHF of a group media, comprised:
(1) media-independent service, it provides information model and information bank so that formulate handover decisions effectively.
(2) media-independent command service, it is used for user's control of giving an order and switches relevant link behavior.
(3) media-independent Event Service, it comprises incident and trigger that local and remote interface produces.
The upper strata of described MIH is carried out handover decisions and is carried out link selection according to input and context from MIH.
Described MIHF provides the logical layer in the mobility management protocol stack of mobile node that move to support and network element, and it plays auxiliary and impetus in the handover decisions process.Simplifying the identification of switching occurrence condition and the discovery of effective handover information is the common-denominator target of MIHF.MIHF provides high-rise abstract service, and one group of interface that defines is provided, and the service primitive that these interfaces expose is independent of concrete access technology; MIHF communicates by the relevant interface of specific access technology and the mobility management protocol stack of low layer.
At present, the seamless switching of terminal between heterogeneous network mainly assisted and promote to media-independent handoff functionality (MIHF) entity by media-independent Event Service, media-independent command service and media-independent service, reduce switching delay and loss of data, strengthen user's experience.The media-independent Event Service is supported the remote events of local event and medium type of the same race.Remote events between the different media protocol stacks is unassisted.Described local event is meant: propagated into the MIH of native protocol stack or or sent to local L3MP (3 layer-two mobility management agreement) by local MIH by L2 data link layer (MAC or Radio Link etc.).The native protocol stack can be positioned at access point such as the AP or the BS etc. of mobile terminal side or network side.Described remote events is meant MIH or the L3MP layer that propagates into the opposite end from MIH or L3MP.
Incident can be used to refer to the change of L2 data link layer transport behavior or the transition of predicted state, or the administration behaviour of indication network side or order.Important incident has: Link_Up (link establishment), Link_Down (link disconnection), Link_Going_Down (link will disconnect), Link_Handover_Imminient (link switchover begins), Link_Parameters_Change (link layer parameter variation) etc.The end that rises of incident comprises L2 data link layer, PHY or MIHF.Difference according to the end that rises can be divided into incident again: Link incident (end that rises is the incident of MIH lower floor) and MIH incident (end that rises is the incident of MIHF layer).The destination of wherein said Link incident comprises the MIH of native protocol stack and/or the MIH of remote protocol stack etc.; The destination of MIH incident comprises the layer 3 of this locality and/or far-end, perhaps other upper layer entity.The destination of incident adopts dynamic registration mechanism, as register own interested particular event by Link_Event_Register.request (link event register requirement) and Link_Event_Register.confirm (link event accreditation verification) message.The destination of incident need obtain the tabulation of Link incident and the tabulation of MIH incident before the register requirement of initiated event.The destination of incident mainly obtains the Link list of thing by Link_Event_Discover.request (link event is found request) and Link_Event_Discover.confirm (link event is found to confirm) message at present, obtains the tabulation of MIH incident by MIH_Capability_Discover.request (request of MIH ability discovery) and MIH_Capability_Discover.confirm (affirmation of MIH ability discovery) message.
The description of the Prior Art relevant with the present invention the discovery of local event, registration and unregistration flow process, as shown in Figure 2:
At first upper layer entity by Event_Discover.request (incident find request) message to its incident of being supported of bottom entity requests, the bottom entity sends the incident of oneself supporting to upper layer entity by Event_Discover.confirm (incident is found to confirm) message, upper layer entity is registered interested incident by Event_Register.request (event registration request) and Event_Register.confirm (event registration affirmation) message then, or by Event_Deregister.request (incident de-registration request) and Event_Deregister.confirm (incident is nullified and confirmed) message the incident of having registered is nullified.When bottom entity when event occurs, the bottom entity is by Link_Event.indiction (link event indication) and MIH_Event.indiction (indication of MIH incident) message informing upper layer entity.
In the prior art, the upper layer entity of system have only the incident of bottom entity registered earlier after, could the service of receiving media extraneous events.The upper strata register of event is divided into MIH event registration and Link event registration, the register of event process is: the upper layer entity of system at first, as MIH User, send MIH_Event_Register.request (request of MIH event registration) message to the MIH layer, the MIH layer passes through Link_Event_Register.request (link event register requirement) message to bottom entity initiated event register requirement then, the bottom entity is confirmed the incident and the state thereof that succeed in registration to the MIH layer by Link_Event_Register.confirm (link event accreditation verification) message, the MIH layer is again by the advisory upper layer entity of MIH_Event_Register.confirm (affirmation of MIH event registration) message with event registration, as MIH User (MIH user).Only comprise EventSource (the bottom entity produces the position of incident) and ResponseEventList (list of thing) information element in described Link_Event_Register.confirm message and the MIH_Event_Register.confirm message, and do not comprise the failure reason could that registered events is failed, so MIH User can not make rational processing according to the reason of registered events failure.In summary it can be seen that there is following defective in prior art:
The upper layer entity of system can not obtain the failure reason could of registered events failure, thereby upper layer entity can not be made rational processing according to the reason of registered events failure.
Summary of the invention
The purpose of this invention is to provide the method for obtaining service failure reason in a kind of heterogeneous network, after bottom registers entities incident or these affairs failures of Logout Events, the upper layer entity of system can get access to the failure reason could of these failure affairs, thereby can be according to different failure causes, select rational processing mode, and then improve the switching efficiency of system.
The objective of the invention is to be achieved through the following technical solutions:
The invention provides the method for obtaining service failure reason in a kind of heterogeneous network, it comprises:
A, after the failure of the bottom entity handles affairs of system, will the fail failure cause information of affairs and described failure affairs of bottom entity reports upper layer entity;
The information that B, described upper layer entity report according to described bottom entity is obtained the failure cause of failure affairs and described failure affairs.
Wherein, described steps A specifically comprises:
A1, after the failure of the bottom entity handles affairs of system, will the fail failure cause information of affairs and described affairs of bottom entity reports the MIH layer entity;
A2, described MIH layer entity pass to described upper layer entity with the failure cause information of described failure affairs and described affairs.
Wherein, described steps A 1 specifically comprises:
After the bottom registers entities incident failure of system, the bottom entity reports the MIH layer entity by Link_Event_Register.confirm message with registration failure incident and corresponding failure cause information;
Or,
After the bottom entity of system was annotated the incident failure that disappears, the bottom entity will nullify turkey by Link_Event_Deregister.confirm message and corresponding failure cause information reports the MIH layer entity.
Wherein, described steps A 2 specifically comprises:
After the MIH layer entity received the information that the bottom entity of system reports, the MIH layer entity will register or nullify turkey by MIH_Event_Register.confirm message or MIH_Event_Deregister.confirm message and corresponding failure cause information reports described upper layer entity.
Wherein, comprise in described Link_Event_Register.confirm message, Link_Event_Deregister.confirm message, MIH_Event_Register.confirm message or the MIH_Event_Deregister.confirm message:
The reason tabulation ReasonFailEventList parameter of registered events or Logout Events failure.
Wherein, described ReasonFailEventList parameter comprises:
Failure cause information corresponding with registered events failure affairs or Logout Events failure affairs are corresponding loses cause information.
Wherein, also comprise in described Link_Event_Register.confirm message or the MIH_Event_Register.confirm message:
Affairs, and the execution result information of the event source of corresponding described affairs and described affairs, described transaction packet explanatory note in brackets volume incident or Logout Events.
Wherein, described step B also comprises:
Upper layer entity is handled described failure affairs according to the different reasons of failure affairs failure.
As seen from the above technical solution provided by the invention, the present invention is after the affairs in the bottom entity of system failures, and will the fail failure cause information of the affairs and the affairs of failing of bottom entity reports upper layer entity; The information that described upper layer entity reports according to described bottom entity is obtained the failure cause of failure affairs and described failure affairs.After bottom registers entities incident or these affairs failures of Logout Events, the upper layer entity of system can get access to the failure reason could of these failure affairs, thereby can select rational processing mode according to different failure causes, and then improve the switching efficiency of system.
Description of drawings
Fig. 1 is the realization configuration diagram of 802.21 agreements;
Fig. 2 is discovery, the registration and unregistration flow process of local event in the prior art;
Fig. 3 is the flow chart of first embodiment provided by the invention.
Embodiment
The invention provides the method for obtaining service failure reason in a kind of heterogeneous network, its core is: after the affairs in the bottom entity of system failures, the bottom entity cause information that affairs and described affairs fail of will fail reports upper layer entity; The information that described upper layer entity reports according to described bottom entity is obtained the failure cause of failure affairs and failure affairs.
The main thought of first embodiment provided by the invention is: by carry the fail parameters R easonFailEventList of this affairs failure of explanation registered events in the Link_Event_Register.confirm of prior art message and MIH_Event_Register.confirm message, make upper layer entity obtain the reason of bottom entity affairs failure, its flow process comprises still as shown in Figure 3:
Step 1, the upper layer entity of system sends MIH_Capability_Discover.request (request of MIH ability discovery) to the MIH layer, and the MIH layer is found request by Link_Event_Discover.request (link event is found request) message to bottom entity initiating capacity then.
Step 2, the bottom entity reports the event information of oneself supporting by Link_Event_Discover.confirm (link event is found to confirm) message to the MIH entity, and described MIH entity reports relevant information by MIH_Capability_Discover.confirm (affirmation of MIH ability discovery) to upper layer entity.
Step 3, the situation that reports according to the bottom entity when the upper layer entity of system, when decision is initiated registration to interested incident, then send MIH_Event_Register.request (request of MIH event registration) to the MIH layer, the MIH layer passes through Link_Event_Register.request (link event register requirement) message to bottom entity initiated event register requirement then.
Step 4, the bottom entity passes through Link_Event_Register.confirm (link event accreditation verification) message to the implementation status of MIH layer reported event registration and the information such as failure cause of corresponding failure affairs, the MIH layer is notified upper layer entity by MIH_Event_Register.confirm (affirmation of MIH event registration) message with described information again, as MIH User (MIH user).
In this step, after the bottom registers entities incident failure of system, the bottom entity passes through Link_Ever_Register.confirm message with these affairs, and the event source of these affairs and the execution result information of these affairs of execution take place, and the information such as failure cause of corresponding failure affairs report the MIH layer entity.After the MIH layer entity received the information that the bottom entity of system reports, the MIH layer entity passed to described upper layer entity by MIH_Ever_Register.confirm message with relevant information.In described Link_Ever_Register.confirm message and MIH_Ever_Register.confirm message, comprise EventSource (event source), ResponseEventList (event response tabulation) and ReasonFailEventList (tabulation of registered events failure cause) parameter.
Wherein said EventSource parameter has been put down in writing the position that bottom produces incident.Described ResponseEventList parameter has been put down in writing the execution result of list of thing and affairs, and as registering result, described list of thing definition is as shown in table 1:
| Title | Value |
| ResponseEventList | For each, when this is the event registration success Bit #0:Link Up Bit #1:Link Down Bit #2:Link Going Down Bit #3:Link Detected Bit #4:Link Parameters Change Bit #5:Link Event Rollback Bit #6:Link SDU Transmit Success Bit #7:Link SDU Transmit Failure Bit #8 ~ 31:Reserved of 1 this correspondence of explanation |
Table 1
As can be seen from Table 1, the execution result of each the expression affairs in the list of thing is relevant informations such as success or failure as registering result.When transaction execution results is successfully the time, then this position is set to 1; When transaction execution results was failure, then this position was set to 0.
ReasonFailEventList parametric representation wherein is the failure reason could of failure affairs, and this table definition is as shown in table 2:
| FailCount | ReasonId【1】 | … | ReasonId【FailCount】 |
Table 2
In the table 2, FailCount represent the to fail quantity of affairs, span is corresponding with the incident number of ResponseEventList definition, Reasonld is the failure cause of failure affairs among the ResponseEventList, arrange in order, its type can be a byte, also can be other type.
Described ReasonFailEventList parameter also can adopt other data structure except that adopting structure as described in Table 2, also can be dissolved in the ResponseEventList parameter.Its essence all is to carry out the explanation of failure cause at each failure affairs.
Equally, the situation that reports according to the bottom entity when the upper layer entity of system, when decision is initiated to nullify to uninterested incident, then execution in step 5, promptly send MIH_Event_Deregister.request (MIH incident de-registration request) to the MIH layer, the MIH layer passes through Link_Event_Deregister.request (link event de-registration request) message to bottom entity initiated event de-registration request then.
Step 6, the bottom entity is nullified the execution result of these affairs and the information such as failure cause of corresponding Logout Events failure affairs by Link_Event_Deregister.confirm (link event nullify confirm) message to MIH layer reported event, the MIH layer is notified upper layer entity by MIH_Event_Deregister.confirm (the MIH incident is nullified and confirmed) message with described information again, as MIH User (MIH user).
In described Link_Event_Deregister.confirm and MIH_Event_Deregister.confirm message, comprise equally as the information in the step 4, be not described in detail here.
Afterwards, the different failure causes of the failure affairs that report according to the bottom entity of upper layer entity are handled described affairs.For example, suppose that the failure cause of these affairs of event registration does not exist for the affairs source of supporting these these affairs of event registration, upper layer entity will be cancelled these affairs of event registration so, enable other switchover policy; If the failure cause of these affairs of event registration is owing to disturbing or other reasons causes, upper layer entity may be selected the mode that re-registers so, or the like.Can make system's rational and effective work more like this, thereby improve the switching efficiency of system.
The above; only for the preferable embodiment of the present invention, but protection scope of the present invention is not limited thereto, and anyly is familiar with those skilled in the art in the technical scope that the present invention discloses; the variation that can expect easily or replacement all should be encompassed within protection scope of the present invention.Therefore, protection scope of the present invention should be as the criterion with the protection range of claim.
Claims (8)
1, obtain the method for service failure reason in a kind of heterogeneous network, it is characterized in that, comprising:
A, after the failure of the bottom entity handles affairs of system, will the fail failure cause information of affairs and described failure affairs of bottom entity reports upper layer entity;
The information that B, described upper layer entity report according to described bottom entity is obtained the failure cause of failure affairs and described failure affairs.
2, method according to claim 1 is characterized in that, described steps A specifically comprises:
A1, after the failure of the bottom entity handles affairs of system, will the fail failure cause information of affairs and described affairs of bottom entity reports the MIH layer entity;
A2, described MIH layer entity pass to described upper layer entity with the failure cause information of described failure affairs and described affairs.
3, method according to claim 2 is characterized in that, described steps A 1 specifically comprises:
After the bottom registers entities incident failure of system, the bottom entity reports the MIH layer entity by Link_Event_Register.confirm message with registration failure incident and corresponding failure cause information;
Or,
After the bottom entity of system was annotated the incident failure that disappears, the bottom entity will nullify turkey by Link_Event_Deregister.confirm message and corresponding failure cause information reports the MIH layer entity.
4, method according to claim 2 is characterized in that, described steps A 2 specifically comprises:
After the MIH layer entity received the information that the bottom entity of system reports, the MIH layer entity will register or nullify turkey by MIH_Event_Register.confirm message or MIH_Event_Deregister.confirm message and corresponding failure cause information reports described upper layer entity.
5, according to claim 3 or 4 described methods, it is characterized in that, comprise in described Link_Event_Register.confirm message, Link_Event_Deregister.confirm message, MIH_Event_Register.confirm message or the MIH_Event-Deregister.confirm message:
The reason tabulation ReasonFailEventList parameter of registered events or Logout Events failure.
6, method according to claim 5 is characterized in that, described ReasonFailEventList parameter comprises:
Failure cause information corresponding or the corresponding failure cause information of Logout Events failure affairs with registered events failure affairs.
7, method according to claim 5 is characterized in that, also comprises in described Link_Event_Register.confirm message or the MIH_Event_Register.confirm message:
Affairs, and the execution result information of the event source of corresponding described affairs and described affairs, described transaction packet explanatory note in brackets volume incident or Logout Events.
8, method according to claim 1 is characterized in that, described step B also comprises:
Upper layer entity is handled described failure affairs according to the different reasons of failure affairs failure.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB200610072670XA CN100459813C (en) | 2006-01-10 | 2006-04-07 | Method for obtaining service failure reason in heterogeneous network |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200610000274 | 2006-01-10 | ||
| CN200610000274.6 | 2006-01-10 | ||
| CNB200610072670XA CN100459813C (en) | 2006-01-10 | 2006-04-07 | Method for obtaining service failure reason in heterogeneous network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1984463A CN1984463A (en) | 2007-06-20 |
| CN100459813C true CN100459813C (en) | 2009-02-04 |
Family
ID=38166591
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB200610072670XA Expired - Fee Related CN100459813C (en) | 2006-01-10 | 2006-04-07 | Method for obtaining service failure reason in heterogeneous network |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100459813C (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101442397B (en) * | 2007-11-23 | 2012-07-04 | 中兴通讯股份有限公司 | Transmission method for reason value |
| JP5698843B2 (en) | 2010-08-13 | 2015-04-08 | 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． | Method for providing information, mobile station apparatus, base station apparatus, and communication apparatus |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6331906B1 (en) * | 1997-02-10 | 2001-12-18 | Oni Systems Corp. | Method and apparatus for operation, protection and restoration of heterogeneous optical communication networks |
| CN1489354A (en) * | 2002-10-09 | 2004-04-14 | ����ͨѶ�ɷ�����˾ | Method and system for realizing inter communication of telecommunication business between isomerized networks |
| CN1520104A (en) * | 2003-09-02 | 2004-08-11 | 中国科学院计算技术研究所 | Method for raising transmission performance of TCP in isomerous networks |
-
2006
- 2006-04-07 CN CNB200610072670XA patent/CN100459813C/en not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6331906B1 (en) * | 1997-02-10 | 2001-12-18 | Oni Systems Corp. | Method and apparatus for operation, protection and restoration of heterogeneous optical communication networks |
| CN1489354A (en) * | 2002-10-09 | 2004-04-14 | ����ͨѶ�ɷ�����˾ | Method and system for realizing inter communication of telecommunication business between isomerized networks |
| CN1520104A (en) * | 2003-09-02 | 2004-08-11 | 中国科学院计算技术研究所 | Method for raising transmission performance of TCP in isomerous networks |
Non-Patent Citations (4)
| Title |
|---|
| Section 1 Modifications. Andrea Francini, Peretz Feder.IEEE 802.21 Media Independent Handover Services. 2005 |
| Section 1 Modifications. Andrea Francini, Peretz Feder.IEEE 802.21 Media Independent Handover Services. 2005 * |
| 数字移动通信. 郭梯云 杨家玮 李建东，479，人民邮电出版社. 2001 |
| 数字移动通信. 郭梯云 杨家玮 李建东，479，人民邮电出版社. 2001 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1984463A (en) | 2007-06-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100488142C (en) | Method for switching between heterogeneous networks | |
| JP4188743B2 (en) | Method and associated apparatus for improving accuracy of geographically different agent topologies between heterogeneous access networks | |
| CN101166357B (en) | Method, device and system for spanning heterogenous network calling terminal equipment | |
| CN101120600B (en) | Method of releasing link connection after handover in multi-mode mobile terminal and terminal thereof | |
| EP1959621A1 (en) | A method and device for managing the power in the isomery network handover | |
| WO2014183715A1 (en) | Gateway update information notification method, and controller | |
| JP2011211710A (en) | Efficient deployment for mobility management entity (mme) with stateful (maintenance of communicating condition) geographical redundancy | |
| CN101102584A (en) | A method and device for switching between isomerous wireless communication systems | |
| US9232453B2 (en) | Method and device for processing AT command when mobile phone loses coverage and switches between systems | |
| CN101146328A (en) | Link parameter threshold configuration method and device in media independent switching | |
| US8514808B2 (en) | Method and function for maintaining mapping between media independent handover functions and transport addresses | |
| CN1968252B (en) | Media-independent link switching method | |
| CN100459813C (en) | Method for obtaining service failure reason in heterogeneous network | |
| CN100558185C (en) | Mobile communication system and paging method thereof | |
| CN104135747B (en) | Mobile IPv 6 node switching method and mobile IPv 6 node | |
| CN110944367A (en) | 4G and 5G interoperation method | |
| CN100512145C (en) | Method for knowing the change information of the event source in the heterogenous network | |
| CN103024838B (en) | A kind of method supporting the reorientation of relay node services gateway | |
| WO2007121671A1 (en) | A terminal handover method and system between the heterogeneous networks | |
| CN101060710B (en) | A method for rapid selecting the link in the media independent switching technology | |
| CN100531437C (en) | Method for obtaining supported service information by independent medium switching functional entity | |
| CN101146331B (en) | Switching method and system based on media-independent switching technology | |
| CN101212486A (en) | Parameter information acquisition method, system, and parameter information feedback device | |
| CN101207917B (en) | Method, apparatus and communication system for interactive information in the course of media independence switch | |
| CN101026868A (en) | Media independent switching device and method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| C17 | Cessation of patent right | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20090204 Termination date: 20130407 |